FDE vs consultant: who pays for your time, and where does the code go?

Picture this. It is Tuesday of the third week of a deployment, and the customer makes a reasonable request: the agent you built needs to read one more kind of shipping invoice, in their own format. You write a parser in two days. It works, and the customer is happy.

The real question comes next: where does that code go after those two days? If it stays in the customer’s repo and nobody at your company knows it exists, then that week you did a consultant’s job, whatever your title says.

The confusion between the two roles is about more than labels. Gergely Orosz, author of The Pragmatic Engineer, has observed that FDE roles at AI labs look a lot like the work of outside consultants or system integrators.

He has also warned that the role is close to becoming indistinguishable from solutions architect or consultant. If you work as an FDE or want to become one, knowing where that line sits helps you do the right work each day and apply to the right companies.

Two questions that separate an FDE from a consultant

The first question is who pays for your hours. According to a comparison by Webfuse, an FDE works for a product company, where deployment helps sell the software and keep customers. For a consultant, their time is usually the product being billed to the client. An FDE’s time is a cost the product company pays itself.

This has practical consequences. A consultant has a rational incentive for the work to run longer, because every hour is paid for. A product company wants to spend as few FDE hours as possible for the same result, so it wants today’s work for one customer to become a reusable feature for tomorrow’s.

The second question goes straight to that point: does the work you do for one customer make it back into the product? A practitioner writing on Substack argues that what separates FDE work from “expensive consulting with a nicer title” is a single design decision inside the company.

That decision is the feedback loop: the FDE team builds something for one customer, then brings it back to the product team to be generalised.

What differences show up on site with the customer?

Two business models lead to two ways of working. SD Times describes good FDEs as starting to deliver value within a few weeks by shipping production-ready products. FDE teams are also small, usually no more than six people, while consulting teams are often larger.

Appetite for risk differs too. SD Times also says consultants tend to choose proven solutions over the newest options. That choice makes sense: when hours are what you sell to the client, a new tool that breaks is a risk that sits entirely inside the contract.

Aspect	FDE	Consultant
Who pays for the hours	The product company, as a cost	The client; the hours are what is sold
What the deployment is for	Helping the company sell and retain software	It is the billed service itself
Team size	Small, usually no more than six people	Often larger

Even so, do not read this table as a ranking. SD Times argues that FDEs complement traditional consultants rather than replace them, filling gaps where consultants are usually weaker.

The line is also blurring from the vendors’ side. OpenAI has set up a separate entity, the OpenAI Deployment Company, and bought Tomoro, a UK AI company, as its first acquisition: a step towards the services model.

Example: one invoice parser, two outcomes

Back to the shipping invoice parser. Done the consultant’s way, you write the parser, write the handover document and log the hours on your timesheet. The work is good, the client gets what they paid for, and the story ends there.

Done the FDE’s way, the code is identical, but you spend 15 more minutes when you finish. You write a short note to the product team, along these lines:

Customer: [customer name], logistics
Request: agent reads shipping invoices in a custom format
Built: custom parser, in production since [date]
Why the product couldn't do it: no way yet to declare a custom document format
General proposal: configure formats instead of writing code for each customer
Question for PM: are other customers hitting this problem?

Now imagine that by the third deployment, a colleague at another customer writes a similar parser and sends a note too. The PM now has two independent signals instead of one vague complaint.

By the fourth customer, you may only need configuration, not new code. Your hours have become a feature, and that is exactly why the company is willing to carry your cost.

How to do it yourself

Whenever you get a customisation request, ask yourself three questions before opening the editor. Will this reach production within weeks, or stay a demo for ever? Which part is true only for this customer, and which part could hold for others? Who on the product team needs to know about it?

Then split the code into two layers from the start: the customer-only part and the part that could be generalised. That split makes it far easier for the product team to pick the work up than a single block that mixes the customer’s field names, paths and logic. Finally, send the feedback note the same week, while the details are fresh.

Mistakes that turn an FDE into a consultant

The most common mistake is never closing the feedback loop. You are busy, the customer is in a hurry, the note keeps getting put off, and six months later you have a pile of custom parsers nobody at headquarters knows about. You cost what an FDE costs and deliver what a consultant delivers.

Another is caution by habit. Choosing proven solutions makes sense in a services model, but the advice here is not to default to it. Weigh each technology choice by whether it helps you reach production within weeks and bring lessons back to the product.

Also, do not let scope grow without asking again who is paying, because every request seems reasonable when you are sitting next to the customer.

Job ads and CVs answer the same two questions

When you read an FDE job description, look for mentions of working with the product team or feeding back into the roadmap, or whether it is all “deliverables”, “per contract scope” and “billable hours”. The latter is usually consulting under a new name. That is not bad, but you should know which job you are taking.

On your CV, do not just write “deployed solutions for customer X”. Write each bullet point in three parts: what you did for the customer, how long it took to reach production, and what the product team learned from it. Put the most effort into the last part, because that is where you show you closed the feedback loop, the thing that separates FDE work from consulting.

Next time you finish some code for a customer, ask before you commit: does this code have a chance of making it back into the product? The answer tells you whether you were an FDE or a consultant that day.