Most outsourcing goes wrong in the seams: who decides, who reviews, who is accountable when something slips. So this page documents the whole thing — every stage from first conversation to clean exit, how people are vetted, how delivery is run and reported, how your data and IP are handled, and what we need from you for any of it to work.
Bench first, then network — re-screened against your context.
Interviews, contracting and onboarding included.
Written, with a first meaningful pull request inside two weeks.
Each stage lists what happens, what we need from you, and what you actually receive. Durations are the ones we hold ourselves to, not the ones that read best.
Everything starts with a written brief. We want the problem before the job spec: what the product does, who uses it, what is blocking, what has already been tried, and what a good outcome looks like six months out. If you already know exactly which roles you need, tell us that instead — we will not manufacture a discovery exercise you do not need.
We search our bench first, then our network. Every candidate you see has already passed our vetting and has been re-screened against your specific context — your stack, your domain, your working hours. We send a small shortlist with reasoning, not a stack of CVs for you to filter.
You interview however you normally would — technical screen, pairing session, system design, culture conversation. We schedule it, brief the candidate on your context so they arrive prepared, and debrief afterwards. You decide. We never place someone you have not met and approved.
One master services agreement covers the relationship; individual engagements are added as schedules, so growing the roster later does not restart legal. IP assignment, NDAs, data processing terms, notice periods and rates are all settled here — never left to the end.
Ramp is a plan, not a hope. Every person starts against a written 30-day plan with a first task chosen to produce a real pull request quickly. We handle equipment, accounts and the administrative drag; you provide access and the context only you have.
From here the rhythm depends on the model. Extension engineers run inside your process. Squads run our cadence and report weekly. Partnerships run to phase gates. In every case the intent is the same: no surprises, and never a status update that has to be chased.
Roadmaps change. Adding people follows the same path, compressed, because the context is already shared. Reducing the team runs through the notice cycle with a handover plan, and we take the person's next placement onto our books. Exiting entirely is a documented process, not a negotiation.
We are a talent sieve, not a marketplace. Every stage tests something the previous one could not, and every stage has a named person who signs off — the last one being you.
Track record, seniority claims, notice period, overlap hours, English fluency in conversation.
Signed off by Talent leadDepth in their primary stack, debugging under questioning, trade-off reasoning, honesty about gaps.
Signed off by Senior engineer in the same disciplineHow they work when they do not know the answer: decomposition, questions asked, path to a working solution.
Signed off by Interviewing engineerJudgement on someone else's code — what they flag, what they let pass, how they phrase it.
Signed off by Senior engineerApplied only above senior level: scaling, failure modes, data modelling, cost awareness.
Signed off by ArchitectReferences from people who managed or worked beside them — never recruiter references.
Signed off by Talent leadYour loop. The final gate, and the only one that matters for placement.
Signed off by YouReferences come from operators — people who managed or worked beside the candidate — never from recruiters. And no stage substitutes for the last one: we do not place anyone your own team has not interviewed and approved.
Capacity is easy to buy and hard to keep useful. These are the practices that keep a team producing work you would have accepted from your own engineers.
Two-week sprints by default, with planning at the start, a demo at the end, and a retro that produces at most three actions someone owns. Continuous-flow teams run the same reporting rhythm without the sprint boundary; we adapt to what your organisation already understands.
Rosters are built around your working hours, with a stated overlap window per person written into the engagement. Stand-ups happen inside that window and are kept short; anything longer moves to a written thread so people in other windows can follow it.
Agreed in writing at the start of the engagement and enforced in review. The default: code reviewed and approved, automated tests written and passing, documentation updated, feature flagged where risky, deployed to a non-production environment and demonstrated.
Every change is reviewed before merge, no exceptions for seniority. Reviews look for correctness, tests, readability and operational risk. Review comments are written to be useful to whoever reads the code in a year, not to score points.
Unit tests as a baseline, integration tests around the seams that break, and automated end-to-end coverage of the flows that generate revenue. CI runs the suite on every pull request; a red pipeline blocks the merge rather than starting a conversation.
Infrastructure as code wherever we own it, reproducible environments, automated deployments with a rollback path, and secrets held in a managed store rather than a configuration file. Where you already have a pipeline, we work inside it.
Architecture decision records for choices that are expensive to reverse, runbooks for anything that can page someone at night, and a setup guide kept accurate by the next person who follows it. Written as work happens, not reconstructed at the end.
A named delivery contact, a stated response window for issues raised in writing, and a path to a partner if that is not enough. You should never have to work out who to call.
Reporting is written, not verbal, so it survives holidays, handovers and the person who was not on the call.
Everything below is contractual, not aspirational. Where your policies are stricter than our baseline, we match them and price them in rather than discovering the gap during a vendor review.
Least privilege by default, granted through your identity provider so you can revoke everything in one place. Access is reviewed when roles change and removed as part of offboarding, not after it.
Disk encryption, screen lock, managed updates and endpoint protection as a baseline. Where your policy requires managed devices, VDI or restricted networks, we match it and price it into the engagement rather than negotiating it later.
Mutual NDA before commercial detail is exchanged, and an individual NDA signed by every person who touches the engagement. Client work is never used as a portfolio piece without written permission.
Assigned to you contractually, and assigned again in each engineer's own agreement so the chain is unbroken. Work lives in your repositories and your cloud accounts from the first commit.
Production data stays in production. Development and test environments use anonymised or synthetic data, and where regulated data is unavoidable we agree the handling rules in writing before anyone gets access.
A defined path for security incidents: contain, notify you within the agreed window, investigate, and produce a written post-incident review with actions. We would rather over-report than manage your risk quietly.
If a placement is not right, we replace the person and absorb the ramp of their replacement.
Nobody joins your team without passing your own interview loop first.
Rolling terms after the initial period, notice in both directions, and a handover process defined before you need it.
Whatever the size of the roster, finance receives a single monthly invoice with a per-role breakdown.
Engagements rarely fail on engineering skill. They fail on decisions, access and feedback. Here is the honest list, with the failure mode attached to each item.
| What we need | Why it matters | What happens without it |
|---|---|---|
| A decision-maker who is reachable | Most delay in engineering is waiting, not building. | Work stalls in review while the team invents assumptions to keep moving. |
| Access on day one | Repositories, environments, tooling and a route to domain answers. | You pay for a ramp week that produces nothing but access tickets. |
| Priorities that hold for a sprint | A team can absorb changing direction; it cannot absorb it weekly. | Velocity collapses and nobody can tell whether the team or the process is at fault. |
| Honest context about the codebase | We would rather know about the fragile module now. | Estimates built on a false picture, then re-litigated after the first surprise. |
| Feedback while it is small | A concern raised in week two costs a conversation; in month three it costs a replacement. | Both sides discover the relationship is broken at renewal. |
| A definition of done you will stand behind | Quality is a shared decision, and it has a cost either way. | Endless rework, or a shipped product nobody will put their name to. |
Write the brief and we will come back with a read-back of what we heard, a recommended model, an indicative range and a start date you can plan around.