FDE, consultant, agency or staffing: the difference, and when to choose what

One need, four ways to cover it

The starting point looks the same from one company to the next. A team spends its day copying data from one file into another. A finance department rebuilds the same report by hand every month. The executive can see the problem. What is not obvious is who should be asked to fix it.

Four answers exist on the market: the consulting firm, the software company working on a fixed scope, staff augmentation, and the forward deployed engineer. Proposals often use the same words: advisory, expertise, delivery, transformation. They do not sell the same thing, and they do not answer the same question.

None of these models is better than the others in the abstract. Each has ground where it is the right call, and ground where it costs a lot for nothing. The usual mistake is not picking a bad supplier, it is picking one for a question that is not theirs.

For each model we look at five things: what you are really buying, who carries the risk, who steers day to day, what stays at the end, and the typical case where it is the right choice.

The consulting firm

What you buy. An outside view and an informed decision. The firm frames the problem, compares the options, builds a roadmap and supports the change inside the teams. It produces recommendations, steering committees, sometimes a specification. It does not produce software.

Who carries the risk. You do. The firm commits to the quality of its analysis and to its own schedule. It does not commit to the recommended solution working once built, since it does not build it. If the recommendation is sound on paper but impossible in your information system, the gap shows up later, at somebody else's desk.

Who steers day to day. An engagement director, with a team that rotates by phase. You steer through deliverables and committees, not through the daily work.

What stays at the end. Documents, a view shared across departments, and often something more valuable still: a decision somebody owned. When a topic is stuck because two departments disagree, a credible third party who settles it is worth more than any tool.

The typical case. You do not yet know what to do. The problem cuts across departments, it touches the organisation as much as the technology, and the stakes run over several years. A consulting firm is also the right call when the real work is adoption rather than the tool: changing settled habits belongs to change management, not to code.

The fixed scope software company

What you buy. A written scope, delivered for an agreed price. You describe what you want, the supplier specifies, estimates, builds, tests and delivers. The contract covers a bounded result: these screens, these functions, these interfaces, this data migration.

Who carries the risk. The supplier, but only inside the written scope. That nuance decides success or failure. Everything in the document is theirs. Everything outside it becomes a change request. On a business topic that is poorly understood at the start, most of what matters is discovered during the project, which is to say outside the document.

Who steers day to day. A project manager on each side. You steer by conformity to scope: what has been delivered, what is left, what is drifting. That is control, not exploration.

What stays at the end. An application, documentation, a maintenance contract. The business knowledge stays largely with the supplier, in the heads of the people who made the implementation choices. This is why reversibility is arranged at the beginning and never at the end.

The typical case. The need is stable, known, already solved elsewhere. You can write what you want without getting it wrong. A fixed scope then gives visibility nothing else gives: a firm budget and a date. It suits a documented system replacement, a rebuild with the same perimeter, an integration between two market tools. Before launching one, settle a prior question: build or buy? We covered it in custom software or off the shelf.

Staff augmentation

What you buy. An available skill, inside your team, for the time you decide. A developer, a data engineer, a systems administrator works at your place, on your tools, inside your rituals. You buy working capacity, not a result.

Who carries the risk. You, entirely. The supplier commits to competence and presence. If the person works on the wrong topic, or if nobody tells them what to do, the invoice arrives all the same. Staff augmentation transfers a hiring burden, it transfers no delivery risk.

Who steers day to day. You, and that is the entry condition. Somebody on your side must be able to break down the work, arbitrate priorities, review and approve. Without that role held internally, the engagement drifts quickly, and nobody notices right away.

What stays at the end. The code, and what your team learned sitting next to the person. On a technology that is new to you, a strong profile brings an internal team up to speed faster than a training course. The subject meets the one covered in bringing your teams up to speed.

The typical case. You know what to do, you know how to do it, you are short of hands or of one precise skill for a period. A peak in activity, a departure to cover while you recruit, a sharp expertise on one component. This model is underrated: when internal steering genuinely exists, it is often the simplest answer.

The forward deployed engineer

What you buy. An engineer who comes and watches the real work before writing a single line. They sit next to the people concerned, look at how they work, where the time goes, what they work around. Then they build, on your data, and come back to check the tool is being used. What is bought is not an executed specification: it is a problem that disappears from the daily life of a team. This is the model we practise at Kabaun Studio, described on the FDE as a service page.

Who carries the risk. The supplier, on usage and not only on delivery. The difference shows in the question asked at the end. On a fixed scope you ask: does it match what was written? In forward deployed mode you ask: did the team gain time, and do they still use it when nobody is watching?

Who steers day to day. The engineer steers their own build, with the users, and reports to the business owner. The committee is not removed, it arbitrates priorities instead of approving screens. This assumes a sponsor on your side who can say which irritation goes first.

What stays at the end. A tool in service, the code and the credentials in your hands, and business knowledge written down because it was observed. That is also what lets a first attempt survive going live, a subject detailed in the prerequisites of a business POC.

The typical case. The need is real but badly phrased. Users describe their work through exceptions, special cases and files of their own. Nobody can write the specification because the knowledge sits in the hands, not in the documents. The forward deployed engineer exists for that precise situation: when the specification is what has to be produced, not what has to be received.

Questions to ask before choosing

The model follows less from preference than from a few honest answers. Take these in order, and note the ones where you hesitate.

• Can we write today what we want, without getting it wrong?
• Is the open question strategic, organisational or technical?
• Who, by name, will arbitrate priorities every week on our side?
• What should the supplier be judged on: a deliverable, a date, or observed usage?
• What must we keep at the end: the code, the data, the skill?
• Are the end users reachable, and can we free their time so they can be observed?
• Are we bound by a procurement process that requires a frozen scope and competitive bidding?
• If the project stops tomorrow, what is left that can be used as is?

A simple rule comes out of it. If your hesitation sits mostly on the first question, no fixed scope will save you: the specification has to be produced first, through framing or through time on the floor. If it sits on the third, rule out staff augmentation until the steering role has a name.

Mixed models, which often work best

In practice, the companies that do best do not buy a pure model. They chain two of them, knowing why they switch.

Framing by a consulting firm, then building by a forward deployed engineer. The firm settles what has to be settled at board level: which process stays, which one goes, who owns what. The engineer then takes the floor and builds what remains. The condition for success is that framing stops short of implementation detail. Framing that goes all the way to screens freezes choices nobody has yet tested against real data.

Forward deployed to start, handover to the internal team. This is the most common setup, and it is arranged from the first week. The engineer builds while explaining, in technologies your team can maintain, with repository and hosting credentials on your side. Handover is not an end of engagement ceremony with a meeting and a document. It is side by side work that started long before.

Fixed scope for the known part, forward deployed for the unclear part. A project often contains a perfectly specifiable share, a data migration or a documented interface, and an uncertain one, the new way of working. Splitting them into two contracts avoids paying for flexibility where none is needed, and avoids freezing a scope that still has to move.

Staff augmentation after go live. Once the tool is in service and the knowledge has been passed on, ongoing evolution no longer needs field observation. One profile, steered by your manager, is enough then.

When a forward deployed engineer is not the right choice

An honest model can say when it is useless. Four situations should steer you away.

The need is perfectly specified and stable. If the document exists, if it has been reviewed by the people who will do the work, and if nothing will move during the build, you do not need somebody to come and observe. You need a team that executes well and a committed date. That is exactly what a fixed scope does better than anything else.

An off the shelf product covers the need. Many problems described as unique are very ordinary ones, already solved by a product built for them. Paying for a custom build to recreate standard commercial management is a poor calculation, however well it is run. The same caution applies to simple automations: when a workflow tool is enough, it is enough, and we say so in our comparison of workflow tools and custom work.

You are bound by competitive bidding on a frozen specification. Some organisations, public or not, must buy against a written scope compared line by line across several offers. Forward deployed work sits badly there, because its value lies precisely in what is not yet written. In that setting, time on the floor belongs upstream, to produce the specification, and the tender then runs normally.

You simply lack hands on one technology. If you know what to do, if internal steering exists and the subject is clear, bringing in an engineer to observe the business is a detour. Staff augmentation answers better and more simply.

There is a fifth case, harder to say out loud: when nobody on your side has the time or the mandate to work with the engineer. The forward deployed model assumes access to the teams and a sponsor who decides. Without that, the engagement produces a decent tool nobody uses, and the original problem is still there.

Choose, then check

The right reflex is not to compare suppliers, but to qualify your own situation: what you can write, what you can steer, what you want to keep. The model then follows almost on its own, and it can change along the way without that being a failure. To understand the fourth model and what separates it from the other three, start with our reference page on the forward deployed engineer. If you would rather talk your case through before deciding anything, the diagnostic is made for that: we look at the problem, not at the solution.

Frequently asked questions

Can a consulting firm also build what it recommends?

Some firms have a delivery arm, others work with partners. The question to ask is about commitment: does one contract cover both the recommendation and the go live? When the two are split, decide who carries over the knowledge produced during framing, otherwise it is lost in the handover.

How do we know our need is specified enough for a fixed scope?

A simple test: ask two business people to describe the same process independently, exceptions included. If the two accounts differ on important points, the need is not specified yet, whatever the document says. In that case, produce the specification before buying a closed scope.

Does a forward deployed engineer work on site or remotely?

Both, depending on the subject. What matters is not the location but the access: watching users work, opening the real files, being there when the process breaks. A fully remote engagement can work if that access is organised seriously, otherwise it slides back into a classic project setup.

Can we switch models mid way without starting over?

Yes, provided the code, the data and the credentials sit on your side from day one. That is the one precaution that makes a switch painless. Moving from a forward deployed engineer to an internal team, or from staff augmentation to a fixed scope, is common and healthy when the subject has changed in nature.

Which internal counterpart does each model require?

For a consulting firm, an executive sponsor able to decide between departments. For a fixed scope, a project manager who holds the perimeter and the acceptance testing. For staff augmentation, a technical lead who breaks down and reviews the work weekly. For a forward deployed engineer, a business owner who opens access to the teams and arbitrates priorities.