Capability 10 / 10Technology & Intelligence
We add vetted engineers, AI specialists or a complete delivery squad to your team. They work in your repositories, tools and sprints, with a delivery manager reporting on their output.
An illustrative squad strip. Six role chips (senior backend, delivery manager, tech lead, machine-learning engineer, frontend and QA automation) move from the photographs into a sprint board marked “Sprint 24, day 1 of 10”, which then reads “Squad ready, 6 roles”. A readout shows four and a half hours of overlap between Indian Standard Time and the United Kingdom.
How we work with you
The options differ in who directs the work and how much delivery risk we carry. Vetting, onboarding, security and reporting are the same in all four.
01
One engineer
One vetted engineer joins your existing team to close a named skill gap, such as Go, machine learning or test automation.
02
Two to four engineers
Engineers covering one area, such as mobile, data or test automation, with one contact and peer review before work reaches you.
03
Cross-functional, with a lead
A tech lead, engineers, QA, a designer and a delivery manager, accountable for an outcome on your roadmap rather than hours.
04
A team that becomes yours
We recruit, vet and run the team, then transfer its people, documents and tooling to you on terms agreed at the start.
Illustrative Terms above are typical ranges and are set per engagement. Book a call
Squad builder
Choose a mission, adjust the roles and pick your time zone to see shared hours and meeting times. Capacity, skill coverage and indicative rate-card units update as you go.
This squad builder needs JavaScript. Below is the “Launch an MVP” squad it opens with and all five time-zone windows.
Squad composition9 people
A rate-card unit is one standard monthly engineer rate agreed in your contract; capacity assumes 6.5 focus hours a day over ten working days, after ceremonies and review.
Shared working windowFive zones, 3–8.5 h shared
United KingdomLondon · GMT (UTC+0)4.5 h shared
Your working day09:00–17:30
Squad shift, in your time04:30–13:30 · 10:00–19:00 IST
From late March to late October London runs on BST (UTC+1) and the shared window grows to 5.5 hours.
EU CentralBerlin · CET (UTC+1)5.5 h shared
Your working day09:00–17:30
Squad shift, in your time05:30–14:30 · 10:00–19:00 IST
From late March to late October Central Europe runs on CEST (UTC+2) and the shared window grows to 6.5 hours.
GulfDubai · GST (UTC+4)8.5 h shared
Your working day09:00–18:00
Squad shift, in your time08:30–17:30 · 10:00–19:00 IST
Neither zone observes daylight saving, so the window holds all year. Ceremonies follow the Sunday-to-Thursday working week.
SingaporeSingapore · SGT (UTC+8)5.5 h shared
Your working day09:00–18:00
Squad shift, in your time12:30–21:30 · 10:00–19:00 IST
Neither zone observes daylight saving, so the window holds all year.
US EastNew York · EST (UTC−5)3 h shared
Your working day09:00–17:30
Squad shift, in your time03:00–12:00 · 13:30–22:30 IST
US East needs a later India shift, agreed in the contract and rotated fairly. On EDT (UTC−4), mid-March to early November, the shared window is 4 hours.
Skill coverage7 of 7 met
OnboardingSigned → first merged pull request
An interactive squad builder. Choosing a mission loads a suggested squad; role steppers change the numbers; choosing a time zone shows the shared working window between your day and the squad's shift, with stand-up, planning and review times in both zones. It opens on the “Launch an MVP” mission (one tech lead, two frontend engineers, two backend engineers, one QA automation engineer, one DevOps engineer, one designer and one delivery manager: 9 people, about 91 story points a sprint) and on the United Kingdom window of four and a half hours. A short demonstration changes the mission once, silently, shortly after the panel comes into view, and stops as soon as you touch a control; changes you make are announced below. All figures are illustrative.
Vetting
Engineers assess candidates in the stack the role needs. A named person runs each stage against a written scorecard, and you see the scorecards with the shortlist.
Illustrative pass-throughA funnel narrowing through six stages. Of one hundred applicants for a role, thirty-two pass the profile screen, seventeen the live technical interview, ten the take-home or pairing exercise, seven the system design interview, five the AI-tooling and secure-coding interview, and four the communication and reference check. Those four reach your shortlist. The figures are illustrative.
01 Profile screen Senior engineer, 20 min
We check repositories, commit history and released systems against the experience the CV claims.
32 of 100 continue 32% pass
02 Live technical interview Senior engineer, 60 min
Coding in the role's language under realistic constraints: debugging unfamiliar code, reasoning about complexity and writing a test first.
17 of 32 continue 53% pass
03 Take-home or pairing Tech lead, 2–3 h
A small, realistic problem such as a failing service or slow query, ideally paired so we see how they ask questions.
10 of 17 continue 59% pass
04 System design Principal engineer, 60 min
Sizing, data model, failure modes, idempotency, rollout and rollback, scored on judgement about trade-offs.
7 of 10 continue 70% pass
05 AI tooling & secure coding Tech lead, 45 min
How they use AI assistants and check the output, plus input validation, secrets handling, dependency risk and role-relevant OWASP Top 10 issues.
5 of 7 continue 71% pass
06 Communication & references Delivery manager, 45 min
Written clarity and how they handle disagreement and incidents, plus two references from people who reviewed their code.
4 of 5 continue 80% pass
Skills matrix
We staff at three depths. Working engineers are productive from week one, seniors set the patterns others follow and leads own architecture and review standards. We work with these technologies; no partnership is implied.
Shading shows how readily we can staff that depth today and is reviewed monthly. Ask for a named engineer profile in any cell and we will send the scorecard. Ask for profiles
Onboarding
Each step has an owner and a date. We aim for a merged change in the first week, because it proves access, environment and review all work.
Typical timingsA thirty-day axis. Six of the seven milestones (days 0, 1, 2, 3, 5 and 10) fall inside the first ten days, and the seventh, the fit review, sits at day 30. The first merged pull request is targeted for day 5 and the first sprint demo for day 10. Every date is repeated in the cards below.
Day 0Ours
Signed before anyone is named, with background verification complete.
Day 1Yours
Identity stays in your directory, so access is yours to grant and yours to revoke.
Day 2Both
Ninety minutes with your tech lead, recorded once so the next joiner does not need it live.
Day 3Ours
The environment builds from your README; if it does not, fixing the README is our first contribution.
Day 5Both
A small change such as a bug fix, a new test or a documentation correction.
Day 10Ours
The engineer presents their own work to your stakeholders at the end of the first sprint.
Day 30Both
A short structured review with your team lead: quality, communication, pace and anything to change.
“Ours” takes none of your team's time. “Yours” needs about an hour from someone on your side. “Both” means we do it together.
How we use AI
Engineers use AI assistants to draft code and tests, on your accounts and under the controls below. We report the effect through the four DORA metrics.
A mock editor showing a retry helper in TypeScript. An assistant suggests capping the exponential backoff at five seconds; the engineer accepts it. Below, a pull request drafted by an agent and owned by the engineer passes lint, unit tests, contract tests and a secret scan, and still waits on a required human review.
Where we work from
Teams work on Indian Standard Time (UTC+5:30). Shared hours with your day are set in the contract, including a later shift when your time zone needs one.
Delivery and client-facing teams 01
Delivery management, architecture and client contact for every engagement, including interviews, kick-offs, service reviews and quarterly planning within your shared hours.
Engineering office 02
Engineering, QA and data work, using the same tools, review standards and security controls as New Delhi.
Shared hours, on a 24-hour IST scalePale band: squad shift · Blue band: hours shared with you
Windows assume standard time in each zone. The UK and Central Europe gain an hour of overlap during their summer time; the Gulf and Singapore do not change.
We work remotely by default and plan in-person time around need, such as a kick-off, an architecture week or a launch. The figures below are targets we report against.
Security and IP
Adding engineers to your systems is a security change. Each one comes with the six controls below, written into the contract, so your security team reviews them once.
Governance
Every engagement reports the same numbers on the same schedule. You get the report whether the sprint went well or not.
Committed against deliveredStory points · last six sprints
An illustrative bar chart of sprints 19 to 24. Committed points: 34, 36, 38, 40, 42 and 42. Delivered points: 31, 36, 35, 40, 41 and 42. Under each column, the defects that escaped to production: four, three, three, two, one and one.
Risks and blockersCarried forward until closed
“Sprint 24 closed on commitment. The refunds story moves to sprint 25 until the payments sandbox is open — that is on your side, and I have asked for a date. I am proposing we drop one frontend seat from sprint 27, when the redesign lands.”
Replacement target10 working days Set in each contract.
What you get
Every engagement hands over the same artefacts, whatever its size. The table shows each one’s format, when it arrives and which models include it.
| Deliverable | Format | When it arrives | Individual 6 of 9 | Pod 8 of 9 | Squad 8 of 9 | BOT 9 of 9 |
|---|---|---|---|---|---|---|
| Vetted candidate profiles Two to four profiles per role, each with its assessment record, so you shortlist on evidence. | Profiles + scorecards | D+5Within 5 working days of the brief | Included for Individual | Included for Pod | Included for Squad | Included for BOT |
| Vetted engineers or a delivery squad The same named engineers stay on your account for the full term unless you ask for a change. | Named people | Start dateOn the agreed start date | Included for Individual | Included for Pod | Included for Squad | Included for BOT |
| Role profiles & assessment results The recruiting brief and a score for each stage: live interview, pair programming, system design, AI tooling and secure coding, communication and references. | Scorecards | Pre-interviewBefore you interview | Included for Individual | Included for Pod | Included for Squad | Included for BOT |
| A named delivery manager One person accountable for fit, quality and escalation, reachable inside your agreed overlap hours and named in the contract. | Named contact | Kick-offFrom kick-off | Not applicable for Individual | Included for Pod | Included for Squad | Included for BOT |
| Onboarding plan Access, environment, codebase walkthrough and first task mapped day by day, against a first merged pull request in about a week. | Checklist | Day 0Signed off on day 0 | Included for Individual | Included for Pod | Included for Squad | Included for BOT |
| Delivery metrics Throughput, committed against delivered work, review turnaround and the DORA delivery measures. | Dashboard | Sprint 1From the first full sprint | Not applicable for Individual | Included for Pod | Included for Squad | Included for BOT |
| Monthly engagement review Quality, fit, risk and next quarter’s capacity, reviewed with your engineering lead, with decisions minuted. | Report | MonthlyMonthly, in your calendar | Included for Individual | Included for Pod | Included for Squad | Included for BOT |
| Knowledge transfer & handover plan Architecture decisions, runbooks and environment notes written in your wiki as work happens, so knowledge stays when an engineer leaves. | Docs | Sprint 1+Written from sprint 1, updated each sprint | Included for Individual | Included for Pod | Included for Squad | Included for BOT |
| Transfer and conversion terms For build–operate–transfer: the conversion mechanism, notice, asset list and the order in which people, accounts and documentation move to your entity. | Contract schedule | Start / transferSigned at the start, run at transfer | Not applicable for Individual | Not applicable for Pod | Not applicable for Squad | Included for BOT |
Scroll sideways to see all four models.
Profiles, plans, tickets, documentation and metrics are kept in your own accounts, under your retention and access rules, so the record stays with you when the engagement ends.
If you use a different tracker or wiki, we work in yours.
Reporting is included in every engagement. Each item below is scheduled at kick-off and owned by the delivery manager.
Illustrative Timings are typical and are fixed for each engagement in the statement of work. Request a sample pack
What we measure
These measures show an engineering leader whether added capacity is paying off: speed to first contribution, predictability, quality and retention.
Engineers contribute to your codebase within weeks, without a quarter spent recruiting.
2–4 weekstypical start, with a first merged pull request targeted for day 5
Output, DORA metrics and review data are shared every sprint, so you can see what the team delivers.
97%sprint predictability in the example fortnightly report
Add engineers for a launch and reduce after it, with documentation so knowledge stays with your team.
30–90 daysnotice by model, with a replacement target of 10 working days
Targets Each row shows the target range on that measure’s own scale. We take baselines from your tooling in the first two weeks and confirm each target in writing before reporting against it.
Each measure is drawn as a horizontal scale with its target range marked. The scale ends and the target are also given as text beside each row.
01
From contract signature to an engineer’s first change reviewed, approved and merged in your repository.
≤ 5working days
Lower is better
02
Work delivered against work committed at planning, averaged over three sprints so one bad sprint does not look like a trend.
85–100per cent delivered
Inside the band is better
03
Production defects found within thirty days of a release and traced to our commits, as counted by your own triage.
≤ 1per squad, per sprint
Lower is better
04
DORA’s measure: median time from a change being committed to it running in production. It depends on your release process too, so we baseline it before setting a target. The AI section uses the same target.
≤ 2working days
Lower is better
05
Engineers still on your account twelve months after starting, excluding changes you asked for. Continuity keeps context in the team.
≥ 85per cent at 12 months
Higher is better
06
DORA’s measure: the share of production deployments that degrade service and need a fix, rollback or patch. Defects that never degraded a release are not counted.
≤ 15per cent of deployments
Lower is better
Each measure has a named owner and a slot in the monthly service review. Agree your measures
Services & packages
Add one engineer or AI specialist, a full squad or technical leadership. Everyone is vetted and works in your stack, tools and sprints. Scale up or down as the work changes.
How to buy
How we work with you
Ask a quick question, send a project brief or issue a formal RFQ. The lead for the work reads each one in full, and any services already in your brief go with it.
Or book a thirty-minute call01
For a first conversation, a press request or anything that does not need a scope yet.
You get A reply from a named lead
02Recommended
Goals, audiences, a budget band and timing, so our first reply can outline the work.
You get Options and a first scope after one call
03
Your documents, deadlines and the procurement and security rules the work must meet.
You get Receipt confirmed and a named bid lead
How it is priced
Each package shows its pricing model. Work starts once a written scope and quote are agreed.
Opens a project brief with this package chosen.
In your brief
In your brief
In your brief
| Package | Every engagement includes | Best for |
|---|---|---|
| SquadA dedicated team that works inside your stack and sprint schedule. |
|
Teams with a clear roadmap that need more senior people quickly |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Live brands and products that need a steady team without hiring one |
| EnterpriseA multi-workstream programme with a dedicated team, governance and agreed service levels. |
|
Large organisations running change across markets, portfolios or business units |
Questions
These come up on first calls. Each answer is the one we would give on the call, with a link to the section that supports it.
Answer sheet · Tech Workforce 8 of 8 answered · evidence on this page
Typically two to four weeks from signature. Profiles reach you within about five working days of an agreed brief, and interviews run the following week. Notice periods are the usual constraint. It can be sooner if a suitable engineer is between engagements or already on your account.
Evidenced by The thirty-day onboarding track
Yes, and we expect you to. You interview anyone you choose before a start date is agreed, with each profile’s assessment record in hand. You can decline without giving a reason, and we send the next profile. Everyone you meet has passed our own stages first.
Evidenced by The six vetting stages
Your team leads direct embedded engineers; our delivery manager leads squads against outcomes you agree. Either way, we review quality and fit with you every month.
Evidenced by Who directs the work, by model
Teams work from India, with overlap hours agreed per engagement so stand-ups, reviews and incident response line up with your working day.
Evidenced by The overlap windows, hour by hour
We stay accountable after placement. Engineers are vetted by engineers, supported by a delivery manager and measured on delivery quality. If someone is not the right fit, we replace them.
Evidenced by What is reported every sprint
Tell the delivery manager and we replace them. In the first two weeks we do it at our cost and you are not charged for the time. After that, the replacement follows the window in your contract, with a handover where notice allows. We record the reason and use it to improve how we brief and assess for your account.
Evidenced by The replacement process
What we make for you is yours once it is paid for. Tools we already had stay ours, and you get a free, permanent licence to use them. Engineers work in your repositories under your security policies and NDAs, with least-privilege access revoked on the first day of offboarding.
Evidenced by The six security controls
Yes, on conversion terms agreed in the contract, so a successful engagement can become a permanent hire without a dispute.
Evidenced by Build–operate–transfer terms
Send us your own questionnaire and we will answer it in writing, against the same evidence, whatever its format.
Before you decide
Any of these can be sent before you sign, so you can see what the work looks like before writing a brief.
Send the roles, the stack and your start date. You will get a written answer.
You will speak to a lead who would run the work, and get a straight answer on fit.
Three ways to start
Every engagement starts with a written scope and a quote agreed before work begins.
Choose one of the three ways above
