Forward deployed vs consulting, software and managed services

Four ways to get help

Consulting. A firm of outside specialists studies a question and delivers analysis, recommendations or a plan. Management consulting is the best-known form. The firm is usually independent of any product, and the work is a defined engagement, often priced by time and materials or a fixed fee.

Packaged software. A product your own people operate, usually delivered as a subscription (software as a service) or a license. The supplier builds once and sells many times. You supply the people, the process and the adoption effort.

Managed services. A provider runs a defined function or system for you under an agreed service level, for a recurring fee (overview). You buy the function, not the effort behind it.

The forward deployed model. The provider's own engineers work with you, often inside your organization, to deploy and adapt the provider's product on your data and problems. The role is explained in what a forward deployed engineer is.

The four at a glance

Commercial terms vary enormously, so the pricing column describes common patterns, not rules.

Traditional consulting: strengths and strains

What it does well

• An outside view. A firm that sees many organizations can spot patterns an insider cannot, and is free to say unwelcome things.
• Specialist skills on demand. You can bring in a team for a question that does not justify a permanent hire.
• Independence and credibility. Boards, lenders and regulators often value a third-party opinion.
• Temporary capacity. A short-lived team can absorb a spike in work.

Where it strains

• Deliverables are not outcomes. A strong report can sit unused if nobody owns the change.
• Knowledge leaves. The people who learned your business move on, and the know-how goes with them.
• Cost and dependence. Billable-hour pricing rewards time spent, and repeat engagements can create reliance.
• Slow start. Scoping, proposals and contracting come before the work does.

Packaged software: low marginal cost, with a last-mile problem

What it does well

• Low cost per use. The supplier spreads development across many customers.
• Standard practice built in. Good products encode how the work is usually done.
• Quick to trial. You can often start small and stop easily.

Where it strains

• It still needs a method. The product does not tell your people how to change their work; someone must own that.
• Configuration and integration. Fitting a product to your data and systems is real work, usually left to you.
• Adoption. A tool that is licensed but unused delivers nothing.
• Generic fit. Products are designed for the typical case, and your case may differ.

Managed services: predictable running, slower change

What it does well

• Accountability to a service level. The provider commits to measurable results, such as availability or response time (service-level agreements).
• Predictable running costs and scale. Steady, well-defined work suits a specialist who does it for many clients.
• Focus. Your people stop spending time on work that is not their core.

Where it strains

• Rigidity. Change usually means a contract change, and contracts move slowly.
• Distance. The knowledge sits with the provider, which makes it harder to learn from the work or switch provider.
• Poor fit for fast-changing problems. Ticket-based work is good at repeating a process and weaker at redesigning it.

The forward deployed model: what is different

The distinctive feature is that the people doing the work belong to the product's maker and work on your real data. That changes the incentives. The engineer's goal is a deployment that works and gets used, and what they learn goes back into the product. One engineering newsletter draws the contrast with consultants this way: forward deployed engineers work with a customer over the long term, where consultants tend to make one-off recommendations (newsletter).

What it does well

• Gets a complex product working in your environment. The engineers know the product deeply and are paid to make it fit.
• A tight loop between field and product. Problems found in deployment can change the product for everyone.
• Alignment on use. The vendor's success depends on your adoption, not on the hours spent.

Where it strains

• Cost per head. Skilled engineers embedded with each customer are expensive, so the model suits large or complex deployments. A venture investor's essay says this lowers early gross margins and argues the trade can pay off, while acknowledging that services work limits scalability and can turn a product company into a consultancy (essay).
• Dependence on one vendor. The expertise is about that vendor's product. If your needs move outside it, the engineers can do little.
• One-offs. If fieldwork stays bespoke and never returns to the product, you get custom code only you will maintain.
• Access and security. Outside engineers need access to your data and systems, which takes review and trust.
• Handover is optional unless contracted. Nothing in the model guarantees that your team ends up able to run what was built.

Where the lines blur

In practice the categories mix. Consultancies build and operate software. Software companies sell implementation services. Systems integrators connect products from several suppliers. A forward deployed engineer who spends a month scoping looks a lot like a consultant, and a managed service that adds features looks like software.

So read the contract rather than the label. Who is accountable for what, how is the work priced, who owns the outputs and what happens at the end?

How to choose

Start with the problem, not the category. The table below gives rough leanings, not rules, and real situations often combine models.

A test for every model: who can run it afterward?

Whichever model you choose, the most useful single question is who can run and change the result once the supplier steps back. Ask any supplier for specifics:

• Who will own the result on your side, by name?
• What will be written down: documentation and operating guides (runbooks) your own people can follow?
• How will your team be trained, and who will they call afterward?
• Where will the data, models and configuration live: in your accounts or the supplier's?
• What access and credentials stay under your control throughout?
• How are decisions and assumptions recorded?
• What are the exit terms, and what does leaving cost?

A supplier that answers these precisely is more likely to leave you stronger, whatever label it uses. The glossary defines the terms used above.

A third way: your own people

Our view. The sections above are meant to be even-handed. This one describes the approach we take and sell, so weigh it accordingly.

The four models fall into two kinds. Consulting, managed services and the forward deployed model bring people in from outside. Packaged software gives your own people a product and leaves them to make it work. A third way starts from a different question: what if the people who already know the work were the ones who went forward?

That means your own frontline employees and leaders do the forward work: they scope the problem, run the analysis and make the call. What they get is the support an outside team would otherwise supply:

• Capacity. The analysis, drafting and modeling that would take days of their own time, done for them.
• Method. The structure an experienced team would apply: a scoped question, cited sources, recorded assumptions.
• Experts on call. A specialist for the decision or signature that needs one, for the time it takes rather than a whole engagement.

What it changes about the handover test

The test above asks who can run and change the result once the supplier steps back. Here the answer is the people who did the work. Part of what they learn is tacit knowledge: know-how that is hard to write down or pass on, so keeping the work in-house is one way to keep it. That is the aim of organizational learning: creating, retaining and transferring knowledge within an organization.

Where it does not fit

• It suits knowledge work you can describe, review and act on in your own tools, such as research, analysis, models and documents. It does not replace the engineers a software integration needs, whether they are yours or a vendor's.
• It is not an independent opinion. When a board, lender or regulator wants a third party's view, consulting still fits.
• It asks something of your people: time, and a willingness to lead the work instead of handing it over.
• Where the law requires a licensed professional to sign, a person must still sign.

The role guide covers the same idea from the engineer's side, and the about page explains how we put it into practice.

Where ForwarD²eployed fits, and where our view is not neutral

We publish this reference and we sell a service, so you should know where we stand. ForwarD²eployed is built for the third way above. It puts expertise inside the AI assistant your team already uses, so the help lives in your own tools and your people lead the work and keep what they learn. It is a different pattern from any one of the four models: some of what software offers, some of what consultants offer, and none of the billable hours or seats.

It has limits. It is built for work you can describe, review and act on in your own tools. It is not a large on-site program, and anything the law requires a licensed professional to sign must still be signed by a person. The handover test above applies to us as much as to anyone, so judge us by it. You can read how it works on the about page and the services page.

Frequently asked questions

Sources and further reading

Sources are linked so you can check them. Statements that vary by employer, or that accounts disagree about, are hedged in the text. Found a mistake? Email support@forwardeployed.work and we will correct the page and update its date.

1. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups. Joe Schmidt, a venture investor's essay, 4 June 2025.
2. What are Forward Deployed Engineers, and why are they so in demand?. Gergely Orosz, The Pragmatic Engineer, 12 August 2025.
3. Management consulting. Encyclopedia entry.
4. Managed services. Encyclopedia entry.
5. Software as a service. Encyclopedia entry.
6. Time and materials. Encyclopedia entry.
7. Service-level agreement. Encyclopedia entry.
8. Systems integrator. Encyclopedia entry.
9. Tacit knowledge. Encyclopedia entry, for knowledge that is hard to put into words or hand over.
10. Organizational learning. Encyclopedia entry, for how knowledge is created, kept and passed on inside an organization.