Forward deployed engineering
An engineer inside your team, measured on your outcome.
Every engagement has one. The FDE is not an account manager with a laptop — they are a senior engineer who writes code in your repository, learns your domain, and stays until the thing works.
The premise
A Forward Deployed Engineer is a senior engineer who works inside your organisation on your outcome. Not an account manager with a laptop, not a coordinator who books time with a delivery centre. They write code in your repository, they learn your domain well enough to argue with your domain expert, and they are measured on whether the thing works.
What you get
- A named engineer, introduced before you sign, who does not rotate off to a different account in month two.
- Code in your repository from the first week — commits under their own name, reviewed by your team, in your branching model.
- Access to the whole firm behind them: Techtons, the reference architectures, and the specialists they can pull in for a week without a new contract.
- A written handover document that starts on day one and is updated weekly, so the value of the engagement never sits only in one person’s head.
- Architecture decision records for anything that will still matter in two years, written where your engineers will find them.
- Pairing and code review aimed at your team getting faster, which is the part that outlasts the engagement.
- A replacement on two weeks notice, in either direction, with no argument about it.
How it runs
4 phases, each with a date attached.
Durations below are what this shape of work typically takes with a team of two to four. They move with scope, and the assessment is where they stop being typical and start being yours.
- 01
Match
1 to 2 weeksWe put forward one or two engineers with the specific depth the work needs. You interview them the way you would interview a hire, and you say no if the fit is wrong. We would rather restart the match than staff it badly.
- 02
Landing
Week 1Accounts, repository access, the environment, and the first pull request. The goal for week one is a merged change, however small, because that is the fastest way to find out what is actually broken about your delivery path.
- 03
Steady delivery
Ongoing, reviewed monthlyYour standup, your board, your on-call rotation if that is the arrangement. Progress is reported against your outcome, not against hours booked, and the monthly review is where either side says the shape is wrong.
- 04
Handover and exit
Final 2 to 4 weeksThe handover document has existed since day one, so exit is a rehearsal rather than a scramble: your engineers take the next three changes with the FDE watching, and then the FDE stops being in the room.
What it costs
No rate card on this page, on purpose.
Priced monthly per engineer, not hourly. There is no timesheet, no utilisation target and no change request for a conversation. A three-month minimum, then a thirty-day exit at any point.
The rate varies with seniority and with how much specialist depth the work needs — an engineer who has run four identity governance migrations costs more than one who has run none, and the honest answer is that most engagements want one of each rather than two of the first. We give you a single monthly figure per engineer before you sign, and it does not move unless the scope of the role does.
What we will not do is quote a day rate and then bill for travel, onboarding, or the ramp-up week. The ramp-up is our problem.
A published day rate would be a number we could not stand behind for your specific situation, and every firm that publishes one quotes something different in the room. What we will commit to before you sign is the phase scope, the phase price and the team shape. Use the calculator for the replacement arithmetic against your own seat count.
Normally bought inside
Guide
You have a dev team. We hand them the blueprint.
Fixed monthly. 3-month minimum.
Join
Hire a Forward Deployed Engineer. They sit in your team.
Monthly per engineer. 3-month minimum, 30-day exit.
When not to buy this
3 reasons to walk away.
Every library entry has rows where the honest answer is no. Every service page has this section for the same reason: the cases below are ones we have seen go badly, and we would rather lose the work than deliver into them.
You want capacity, not depth
If the work is well understood and the constraint is simply the number of hands, a body shop will do it for less. FDEs are expensive because they make decisions, and paying that premium for ticket throughput is a waste of your money.
There is nobody to embed with
An FDE works inside a team. If there is no team, no product owner and no decision-maker who can answer a question inside a day, the engagement becomes an engineer waiting, and you are paying for the waiting.
The real problem is organisational
If the reason nothing ships is a governance process, an unresolved reorganisation or two directors who disagree about the roadmap, an engineer in your standup will not fix it. That is a different piece of work and we will say so.
Pick one contract. We will show you the replacement.
A two-week assessment: we take your single most expensive SaaS line item, establish what you actually use, and come back with a parity matrix, an architecture for AWS and Azure, a cost model and a delivery plan. Fixed price. If the answer is keep buying it, we will tell you that.