# Custom code FDEs leave behind: when the FDE leaves, who pays the technical debt?

> On handover day the access is revoked, but the code keeps running, and the only person who understood it has just left the room.

Original: https://fdetimes.net/en/analysis/fde-custom-code-technical-debt/

In the Solenis case described by Valletta Software, handover day ended with a perfectly ordinary step: remote access was revoked. From that day on, a person with no technical background ran the system alone.

There is nothing dramatic about it, which is exactly why it deserves a closer look. Every line of custom code the FDE wrote while on site kept running after that day. Only the person who understood it was gone.

If you are an FDE, or want to become one, the question of who pays this debt is not just a matter for leadership.

It tells you whether the company you are joining is a product company or a consultancy in disguise, and whether you will be judged by what you bring back to the product or by the hours you spend at the customer.

The short answer: when nobody is explicitly assigned, the customer usually pays.

## Project or product: where is the line?

Thomas Otter draws the line bluntly. In his view, if you focus on building at one customer and for that customer alone, you are doing a project, not building a product. He adds that an FDE who bills the customer is working for the project.

Otter quotes Marty Cagan to show what happens when that approach is scaled. Cagan warns that a company made up only of FDEs will quickly end up with thousands of large bespoke solutions. According to Cagan, there has to be a platform-side product role so that what the FDEs learn is consolidated.

David Petersen of Angular Ventures, also quoted by Otter, puts it more sharply: without an effort to standardise, you are probably telling yourself a nice story while quietly building a consultancy.

Chris Degnan, Snowflake's former CRO, speaking on the 20VC podcast in May 2026, called the FDE a dressed-up professional services worker. Let's Data Science interprets his concern as being about technical debt and maintenance landing on the customer.

These views share one point. None of them objects to FDEs writing code for a specific customer. What they object to is that custom code having no path back to the product.

## Debt is not created, it is quietly absorbed

FDE Academy identifies the mechanism precisely: technical debt usually appears when scope creeps and is quietly absorbed, without renegotiation and without documentation. Nobody sets out to create debt. It comes from every "I'll just do it for you".

Take a hypothetical case. In week three, the customer asks for an extra data sync to a legacy accounting system. The FDE builds it in two evenings and the customer is happy, but the work was not in scope, has no documentation, and nobody on the product side knows it exists.

Six months after handover, the accounting system is upgraded and the sync breaks. The person running things is someone like the system owner in the Solenis case: not technical, without the old team's access, and with no documentation to read. Taken one at a time, each of the FDE's decisions was reasonable. Added up, they become a debt with nobody's name on it.

Now multiply. Suppose an FDE team serves 10 customers, each with three small forks like this: that is 30 pieces of code nobody on the product team has ever read. Valletta warns that custom forks of this kind can, at some point, make deploying to new customers impossible.

## Who is assigned to generalise?

Valletta sums up the problem in one sentence: nobody owns generalisation. The piece argues that the core promise of the FDE model is to push whatever can be generalised back into the product, and that the model holds up only when a specific person is accountable for doing it.

Antoine Buteau makes the same point differently: a forward-deployed company does not avoid services, it "digests" them into reusable assets. A company that cannot do that gradually drifts into being a consultancy.

PostHog's FDE handbook takes this line, describing how patterns that repeat across engagements become reusable artifacts, skills and product improvements, with the FDE accountable for outcomes.

One thing is worth noting: even PostHog's handbook does not say who maintains custom code once an engagement ends. Many organisations are clear about what goes back into the product but leave open what stays behind. What stays behind is the debt.

In the end there are only three possibilities. The product team takes the part that can be generalised. The customer takes the rest, under a clear handover agreement. Or nobody takes it, and then the customer usually carries it anyway, only without being told.

**Key point:** When custom code has no owner, the customer is usually the one who carries it.

## Five doors the debt walks through

Debt does not arise at a single moment. Over the life of an engagement it slips through five doors, and at each one there is something an FDE can do straight away.

| Moment | How the debt arises | What the FDE does | Who advises it |
|---|---|---|---|
| Choosing the work | Building a one-off integration for a customer outside the ideal customer profile | Treat it as a distraction and raise it before accepting | Antoine Buteau |
| Mid-engagement | Scope creeps and is absorbed without anyone saying so | Renegotiate, write it down, state the trade-offs | FDE Academy |
| During design | Code is tightly coupled to one customer's systems | Design in modules so the customer-specific part can be separated | FDE Academy |
| After each engagement | The generalisable part is left behind at the customer | Push it back into the product, with a named owner | Valletta Software |
| Handover and after go-live | Domain knowledge leaves with the team; maintenance goes unseen | Write documentation and handover obligations into the contract when hiring an outside team; track custom maintenance even after the account is "live" | Valletta Software, Antoine Buteau |

## What to do at the customer tomorrow

Start with the cheapest door: documentation. Every time the customer asks for more, write one line: what the request is, whether it was renegotiated, which trade-off was accepted. A line like that turns an invisible debt into a decision with an owner.

Next is the design door. Before writing the sync in the example above, ask yourself: which part is specific to this customer, and which part will the next customer also need? The second part belongs in a separate module with a clear interface, so the product team can lift it out without digging through the customer's systems.

Last comes handover. Use the system owner in the Solenis case as the test: could a non-technical person, without the old team's access, run the system alone? If your documentation can only be understood by the person who wrote it, the handover is not finished.

## What this debt says about your career

When interviewing for an FDE role, ask three questions directly. Who is assigned to generalise custom work back into the product? Is there a platform-side product role that consolidates what FDEs learn? How is custom maintenance tracked after go-live? Vague answers are a sign you are about to work for a consultancy.

When reading job descriptions, look for phrases such as "feed back into the product" or "reusable artifacts", the way PostHog describes its work. A description that talks only about customer satisfaction and time on site is hiring for projects, not for product.

On your CV, do not just list what you built for customers. Describe the custom work you turned into reusable modules, the product features that grew out of one of your engagements, and the handover documentation that let a customer run the system on its own. That is evidence you build product, not dressed-up services.

All custom code ends up with someone looking after it. The only difference is whether that person was chosen at the start, or only turns out to be the owner on the day the access is revoked.

**Try this week:**

- Open a scope log for your current engagement: record every new request, whether it was renegotiated, and which trade-off was accepted.
- Review the custom code you have written, label each part 'generalisable' or 'this customer only', and send the list of 'generalisable' items to the product team.
- Give your handover documentation to a non-technical reader and ask whether they could run the system alone if you lost access tomorrow.

## Sources

- [on the forward deployed engineer (Thomas Otter)](https://thomasotter.substack.com/p/on-the-forward-deployed-engineer)

- [The Forward Deployed AI Engineer Model, and What It Costs](https://vallettasoftware.com/blog/post/forward-deployed-engineer-model)

- [Chris Degnan Critiques Forward-Deployed Engineer Role](https://letsdatascience.com/news/chris-degnan-critiques-forward-deployed-engineer-role-e05975bb)

- [Forward Deployed Company Series 4: How Not to Become Accenture](https://www.antoinebuteau.com/forward-deployed-company-series-4-how-not-to-become-accenture.md)

- [How a Forward Deployed Engineer Manages Enterprise Scope Creep Without Creating Tech Debt](https://fde.academy/blog/forward-deployed-engineer-scope-creep-tech-debt)

- [Forward deployed engineering overview (PostHog Handbook)](https://posthog.com/handbook/forward-deployed-engineering/overview)