Services

Three ways to put an engineering team behind your product.

Same standard of craft, different centre of gravity. This page is the long version: what you own, what we own, how a team is composed, how long it takes to ramp, what it costs, and the point at which each model stops being the right one. If you would rather skim, the decision table below is enough.

Choose a model

Start from your situation, not from our menu.

Most engagements are mis-scoped at the beginning, not mismanaged later. Find the row that describes where you are; the last column is the honest cost of that choice.

Where you areThe modelWhy it fitsWhat it costs you
We know what to build, we just need more handsTeam ExtensionYour process is already working; adding capacity is the cheapest interventionYou keep all management overhead
We have a roadmap but nobody to run another teamDedicated SquadYou get one accountable unit instead of five individuals to coordinateYou give up day-to-day control of how work is sequenced
We have a business problem and no engineering orgProduct PartnershipDiscovery, architecture and delivery held by one accountable partyYou trade control for accountability, and pay for the definition work
Headcount is frozen, the roadmap is notTeam ExtensionContracted capacity sits outside headcount and scales back cleanlyBudget moves from people cost to project cost
A whole new surface needs building in parallelDedicated SquadA ring-fenced team that will not be pulled onto core firefightingSix-month horizon before the squad pays back its ramp
A legacy system must be replatformed without breakingProduct PartnershipMigration risk is held by the party doing the migrationPhase gates mean slower starts and firmer plans

Signals you picked the wrong model — and what to do about it.

  • Your engineering manager spends more time coordinating our people than building — you have outgrown team extension.
  • You are reviewing every ticket of a dedicated squad — you wanted extension, not a squad.
  • A partnership keeps waiting on your decisions — the work is really a squad with your product owner in the driver's seat.
  • Nobody can name the person who accepts the work. Whatever the model, fix that before adding people.
Model 01Staff augmentation

Team Extension

Your team, several engineers larger, without a hiring cycle.

We place vetted senior engineers directly inside your existing squads. They attend your stand-ups, write against your definition of done, submit pull requests into your repositories, and report to your engineering manager. Nothing about your process changes — only your capacity does. This is the model to pick when you already know what to build and how you want it built, and the constraint is simply how many capable hands you have.

Pick this when

  • You have an engineering manager or tech lead with capacity to direct people.
  • Your backlog is well understood and the bottleneck is throughput, not clarity.
  • You need a specific capability — DevOps, ML, mobile, security — for a defined stretch.
  • You are covering parental leave, notice periods or a hiring pipeline that is running slow.
  • Headcount is frozen but the roadmap is not.

Do not pick this when

  • There is nobody on your side to set priorities or review work.
  • You want an outcome and a fixed budget rather than capacity.
  • The product has no repository, environment or codebase yet to join.

Who owns what

You own
  • Roadmap, priorities and sprint scope
  • Architecture decisions and code review standards
  • Line management and day-to-day direction
  • Tooling, environments and access
  • Acceptance of work and release decisions
We own
  • Sourcing, vetting and shortlisting candidates
  • Contracts, compliance, payroll and equipment
  • Retention, performance follow-up and replacement
  • Ramp support and technical mentoring behind the scenes
  • A single monthly invoice covering the whole roster

Typical composition

Senior / staff engineer
The default placement — 5+ years, ships without supervision.
Specialist
DevOps, SRE, data, ML, security or QA automation for a defined capability gap.
Pod of three to five
A cohesive group that ramps together and covers for one another.
Backfill cover
Time-boxed replacement for a departing or absent team member.

How it ramps

  1. Day 0-2

    Brief reviewed, role profiles agreed, search opened against our bench and network.

  2. Day 3-7

    Shortlist delivered with CVs, code samples where available, and our interview notes.

  3. Week 2

    Your interviews. We schedule, prepare and debrief; you decide.

  4. Week 2-3

    Contracting, NDAs, background and reference checks, equipment and access.

  5. Week 3-4

    Onboarding into your codebase — first pull request typically inside the first fortnight.

Commercial shape

Billing
Monthly, per engineer, all-inclusive.
Minimum commitment
Three months, then rolling.
Notice
30 days either way after the initial term.
Scaling
Add or remove people at any point in the notice cycle.
Not billed
Sourcing, interviews, replacements, equipment, admin.

Rituals and reporting

  • Your stand-ups, your sprint ceremonies — we do not impose a second process.
  • A monthly check-in between your manager and our delivery lead on performance and fit.
  • A written retro at 30, 60 and 90 days for every placement.
When to move on

When you find yourself directing five or more of our engineers and your own manager becomes the bottleneck, the coordination cost has moved onto your side of the table. That is the point to move to a dedicated squad and hand the delivery management back to us.

Model 02Co-sourced squad

Dedicated Squad

A complete team, run by us, pointed at your product.

We assemble a cross-functional squad — engineers, QA, a delivery lead, design and DevOps as needed — and run it as a unit against your roadmap. You keep product ownership and set direction; we own team performance, delivery cadence, and everything that keeps a team functioning. It is the closest thing to having a second engineering office without opening one.

Pick this when

  • You have a product direction but not the management bandwidth to run another team.
  • You want one accountable group rather than a set of individuals to coordinate.
  • The work will run for two quarters or more.
  • You want a stable team that accumulates domain knowledge rather than rotating contractors.
  • You need a whole capability — a mobile app, a data platform, a new surface — stood up in parallel to your core team.

Do not pick this when

  • The scope is a few weeks of work — a squad never pays back its ramp in that window.
  • You want to direct every individual personally; team extension is the honest fit.
  • There is no product owner available to make decisions on your side.

Who owns what

You own
  • Product vision, priorities and acceptance
  • Business context, users and success metrics
  • Sign-off on releases and scope changes
  • A named product counterpart for the squad
We own
  • Team composition, staffing and replacements
  • Delivery management, sprint planning and estimation
  • Engineering standards, code review and QA gates
  • Environments, CI/CD and release mechanics where you want us to hold them
  • Weekly reporting, velocity and risk registers

Typical composition

Delivery lead
One per squad. Runs planning, reporting and escalation. Non-optional.
Engineers
Three to eight, mixed seniority with at least one senior anchor per discipline.
QA / test automation
From half-time on smaller squads, full-time from roughly six engineers.
DevOps / SRE
Fractional by default; full-time when infrastructure is the product.
Product designer
Added when the surface is user-facing and design is not already covered.

How it ramps

  1. Week 1

    Discovery: goals, constraints, existing systems, definition of done, risks.

  2. Week 1-2

    Squad shape proposed and agreed, named people presented for your review.

  3. Week 2-3

    Contracting, access, environments, tooling and security onboarding.

  4. Week 3-4

    Sprint zero — backlog shaped, architecture agreed, CI green, first increment planned.

  5. Week 4+

    Regular delivery cadence with weekly demos and written reporting.

Commercial shape

Billing
Monthly, per squad, itemised by role.
Minimum commitment
Six months — the horizon where a squad becomes cheaper than coordination.
Notice
60 days after the initial term.
Scaling
Squad shape reviewed each quarter; roles added or dropped by agreement.
Included
Delivery lead, reporting, QA gates, onboarding and handover documentation.

Rituals and reporting

  • Weekly demo of working software, recorded so stakeholders can catch up.
  • Written weekly report: shipped, in flight, blocked, risks, next week's intent.
  • Monthly business review with velocity, quality metrics and budget burn.
  • Quarterly squad review — composition, performance and roadmap fit.
When to move on

When the squad is effectively defining the product as well as building it — deciding scope, trade-offs and sequencing — you are already in a partnership. Making that formal gives you commercial protection and gives us the mandate to say no to the wrong work.

Model 03End-to-end delivery

Product Partnership

You describe the outcome. We own getting there.

We take a product from discovery through architecture, build, launch and the first months of operation. You bring the business problem, the users and the decisions only an owner can make; we bring everything else, including the accountability for whether the thing works. This is the heaviest model we offer and the one with the least ambiguity about who is responsible.

Pick this when

  • You are launching something new and have no engineering organisation to run it.
  • You want accountability for an outcome, not for hours.
  • An internal team is at capacity and a whole initiative needs to happen elsewhere.
  • You are replatforming a legacy system and want one party holding the migration.
  • You need discovery and definition, not just execution.

Do not pick this when

  • You want daily control over how the work is done — that is what a squad or extension is for.
  • Requirements are still moving faster than they can be written down anywhere.
  • Legal or regulatory constraints require your own employees to hold delivery accountability.

Who owns what

You own
  • The business problem, market and commercial goals
  • Decisions on scope trade-offs and launch timing
  • Access to users, stakeholders and domain experts
  • Budget approvals and go/no-go at each phase gate
We own
  • Discovery, requirements and product definition
  • Architecture, technology selection and build
  • Design, QA, security review and release management
  • Infrastructure, monitoring and the first period of operation
  • Documentation, handover and — when you want it — hiring your internal team

Typical composition

Engagement lead
Your single point of accountability across all phases.
Product / discovery
Requirements, user research, scope definition, phase gates.
Architect
System design, technology selection, non-functional requirements.
Delivery squad
Engineering, QA and design sized to the phase, not fixed for the whole project.
Operations
Infrastructure, observability and support during launch and stabilisation.

How it ramps

  1. Phase 0

    Discovery — two to four weeks. Problem, users, constraints, scope, and a costed plan.

  2. Phase 1

    Foundations — architecture, environments, CI/CD, security model, design system.

  3. Phase 2

    Build — increments delivered on a fixed cadence with demos and phase gates.

  4. Phase 3

    Launch — hardening, load and security testing, runbooks, go-live.

  5. Phase 4

    Operate or hand over — stabilisation, then transfer to your team or ongoing support.

Commercial shape

Discovery
Priced separately as a standalone deliverable you own outright.
Build
Phase-based, with a costed plan and gate before each phase begins.
Change
Scope changes are written, costed and approved before work starts.
IP
Assigned to you on payment — code, designs, documentation and infrastructure.
Exit
Handover package and transition support included in the final phase.

Rituals and reporting

  • Phase gates with a written go/no-go decision and updated cost plan.
  • Fortnightly steering call with the engagement lead and your sponsor.
  • Weekly written status: progress against plan, decisions needed, risks with owners.
  • A living decision log so nobody has to reconstruct why a choice was made.
When to move on

Partnership ends well when your own team can hold the product. We plan that exit from the first phase — documentation, runbooks and, if you want it, help hiring the people who take over.

The operating standard

What is true in every engagement, whichever model you choose.

These are not model-specific extras. They are the baseline we hold ourselves to, and the reason a roster can grow without the relationship degrading.

7
Vetting stages

Six on our side, then your own interview loop as the final gate.

1
Invoice per month

Whatever the roster size, itemised by role for your finance team.

0
Cost to replace

A wrong placement is ours to fix, including the replacement's ramp.

A named delivery contact

One person accountable for the engagement, reachable in your working hours, who is not billing you as an engineer.

Structured vetting

Every engineer passes a technical interview, a live problem-solving session, a code review exercise, operator references and a communication screen before you ever meet them.

Onboarding kit

Access checklist, environment setup guide, glossary of your domain, and a 30-day ramp plan written per person.

Your code, your repository

Work happens in your version control under your standards. There is no black box you receive at the end.

Documentation as a deliverable

Architecture decisions, runbooks and setup guides are written as work happens, not reconstructed at handover.

Quality gates

Code review on every change, automated tests in CI, and an agreed definition of done that we hold ourselves to.

Replacement cover

If a placement is not working, tell us. We replace at our cost and carry the ramp of the replacement.

A clean exit

Handover documentation, knowledge transfer sessions and an offboarding checklist — written before you need them.

One invoice

Whatever the roster size, your finance team receives a single monthly invoice with a per-role breakdown.

Commercials

How a rate is actually built.

We do not publish a single day rate, because a single number would be wrong for almost everyone. Here is every input that moves the figure, so nothing in a proposal reads as arbitrary.

Seniority band

Mid, senior, staff and principal are priced differently because they solve differently sized problems. Most rosters are senior-weighted; we will tell you when a mid-level engineer is the honest fit rather than upselling.

Role and scarcity

Platform, ML, security and specialised mobile skills price above general application engineering because the market prices them that way.

Commitment length

A twelve-month commitment prices below a rolling three-month one. Longer commitments let us hold people for you rather than re-sourcing.

Team shape

A squad price includes the delivery lead, QA gates and reporting. Comparing a squad rate to a single contractor rate is comparing different things.

Overlap requirements

Full overlap with a narrow time zone window restricts the pool and prices accordingly. Broad overlap requirements price lower.

What is never billed

Sourcing, interviews, failed placements, replacement ramp, equipment, contracting, admin and the delivery contact on extension engagements.

A brief produces a written proposal with a per-role breakdown, the assumptions behind it, and the notice and scaling terms attached. If our recommendation is a smaller engagement than you asked for, the proposal will say so and explain why.

Questions

The things clients ask before signing.

Answered at the length the question deserves, including the ones that are awkward for us.

01

How quickly can someone actually start?

A shortlist typically lands within a week of a complete brief. From your acceptance, contracting and onboarding usually take a further one to two weeks, so a realistic first-commit date is three to four weeks from the brief. Specialised roles — principal-level ML, niche embedded work, hard compliance constraints — take longer and we will say so up front rather than promising a date we would miss.

02

What happens if an engineer is not working out?

Tell your delivery contact as early as you feel it. We investigate, and if the fit is genuinely wrong we replace the person at our cost and carry the ramp time of the replacement. We would rather absorb that than defend a placement nobody is happy with.

03

What are the notice periods?

Team extension: three-month initial term, then 30 days' notice either way. Dedicated squads: six-month initial term, then 60 days. Partnerships are phase-based, with an exit defined at each gate. Notice runs both directions — the same terms protect you and us.

04

Can we scale down as well as up?

Yes, and it is the point of the model. Roll people off within the notice cycle without severance exposure, employment claims or the political cost of a redundancy process. We handle the person's next placement.

05

Which time zones do you cover?

We staff for overlap with your working day rather than for a particular country. Tell us the hours you need covered and we build the roster around them; where you need follow-the-sun coverage we split the roster across windows.

06

Who owns the intellectual property?

You do. IP assignment is written into every contract and flows through to each individual engineer's agreement. Code lives in your repositories under your accounts from day one, so ownership is a fact of the setup rather than a promise at the end.

07

How do you handle confidentiality and security?

Mutual NDAs before any detail is shared, individual NDAs for every person on the engagement, access on a least-privilege basis through your identity provider, and device policies matched to your requirements. Where you have a security questionnaire or vendor review process, we complete it.

08

Do you subcontract the work?

The people on your engagement are engaged by us and vetted by us. We do not resell another agency's bench without telling you, and you always know who is on the roster because you meet them before they start.

09

Can we hire one of your engineers permanently?

Often, yes. There is a conversion path with a fee that steps down the longer the person has been with you. We would rather help a good placement become permanent than lose the relationship defending it.

10

Whose tools and process do we use?

Yours, in extension engagements — your tracker, your repos, your rituals, your definition of done. In squads and partnerships we bring a working setup by default, and adapt to yours wherever you have an opinion.

11

How is progress reported?

Extensions report through your own process; we add a monthly performance check-in. Squads produce a written weekly report and a live demo, plus a monthly business review. Partnerships add phase-gate documents with costs and decisions.

12

What do you need from us to start?

A brief covering the problem, the stack, the shape of the team and the constraints; a named decision-maker; and access to whoever can answer domain questions. Everything else is our side of the table.

Next step

Tell us the problem. We will tell you the smallest model that solves it.

Six short steps in the brief. You get a written read-back, a recommended model with reasoning, an indicative cost range and a realistic start date — within one business day.