Forward deployed engineering as a service

This page is the build, staff or engage decision, with what each one actually costs you in control and risk.

Route one: build the function

Hire your own embedded engineers.

What it gives you. Full control, accumulated context that stays with you, and a capability that compounds. If embedded delivery is core to how you sell, this is the destination.

What it costs. A hiring cycle for a competitive profile. Across 1,000 postings the role skews mid-level, with 60 percent targeting three to five years, and you are competing with companies paying well. Then two or three engagements of learning before the function is good, because the first engagements are where you find out what generalises and how long production takes at your kind of customer.

The hidden cost. The structural decisions. Where the function reports is the one most companies get wrong, and the hiring data suggests over half already have: only 45 percent of those postings sat on a dedicated forward deployed team rather than under sales.

When it is right. When this is how you sell, when you have enough accounts to keep engineers busy, and when you can carry the learning period. How to build the team is the playbook.

Route two: staff engineers through a partner

Bring in individual senior engineers who work under your direction.

What it gives you. Speed to a person in a seat, flexibility to scale up and down, and no hiring commitment. You keep control of the roadmap and the approach.

What it costs. You keep the delivery risk. If the plan is wrong, that is yours. And the context these people accumulate leaves when they do, unless you deliberately capture it.

The thing to be clear about. This is staff augmentation, and it is an honest model with honest pricing. It becomes a problem when it is sold as forward deployed engineering, because the words are nearly identical and what you are buying is not. FDE vs staff augmentation separates them.

When it is right. When you have senior technical leadership making the calls and you need capacity. If nobody on your side is making those calls, more hands become capacity that waits.

Route three: engage a firm that takes the outcome

Hand a defined outcome to a firm that works this way.

What it gives you. Delivery risk on the other side of the table, a team that has done this before, and no hiring or learning period. The good version also gives you a capability transfer at the end.

What it costs. More per unit of time, less control over how, and a dependency risk if the engagement is not bounded.

The condition. This only works if the contract names a production outcome and a handover date. A firm engaged on time and materials with an outcome-flavoured description gives you the control of neither model, and that is the most common way this route disappoints. How to price and the contract cover the terms.

When it is right. When the deployment matters more than the capability, when you need it now, or when you want to see the model run properly once before building your own.

The comparison

Speed to start. Staff fastest, engage close behind, build slowest by a hiring cycle.

Control over approach. Build highest, staff high, engage lowest.

Who carries delivery risk. Build you, staff you, engage the vendor if the contract says so.

Cost per unit of time. Staff lowest, build middling once you account for unbilled time, engage highest.

What you own at the end. Build a capability, staff nothing durable unless you captured it, engage a running system plus whatever the handover transferred.

Failure mode. Build hires the wrong profile or reports into sales, staff buys hands for a judgment problem, engage never ends.

The hybrid that works

The sequence most companies should follow rather than choosing one route forever.

Engage a firm for the first one or two deployments, with a handover date and a capability transfer written in. Watch how they run it: the discovery, the production path, the artefacts. Then hire your own, using what you learned about what the role actually needs at your kind of customer.

That reverses the usual order, which is to hire first and learn on your own customers. It costs more per deployment at the start and less overall, because the structural mistakes get made on somebody else's time.

AWS built its partner programme on exactly this shape: its engineers embedded with partner teams, then support shifting to helping the partner scale their own practice, then the partner working independently. Capability transfer as the design goal rather than a courtesy.

What we offer, plainly

We do route three, and we will do route two.

On forward deployed engineers we take the outcome: a specification, an eval suite derived from it, a named production date, a named handover date. If it does not run, that is ours.

On staff augmentation you direct the work and we supply senior people.

We will also tell you when the answer is neither. If your scope is writable and your leadership is strong, you want hands and should pay hands prices. If your accounts are too small to carry an engineer, no vendor fixes that. When forward deployed engineering is the wrong answer is the page we would rather you read first.

Next: how to choose a partner.