What a Forward Deployed Engineer actually does all day

I own five companies and I write the software that runs inside them. That is an odd position to write from, and it is the only reason this page exists: most people describing this role are engineers looking at a client, or owners looking at a supplier. I get the invoice and the bug report on the same day.

What does a Forward Deployed Engineer actually do all day?

A Forward Deployed Engineer builds working software inside somebody else’s business, close enough to the people doing the work to see what they actually need. Most of the day goes into understanding a process and cleaning up the data around it. The code itself is usually the smallest part.

The job ads name four things: write production code, break vague problems into engineering tasks, feed pain points back to the product team, and keep everything reliable inside old enterprise systems. All four are real. They are just not the same size.

Which of those four fills most of the day?

Breaking the vague problem down. Almost nobody arrives with a specification. They arrive with a feeling that something takes too long, or a demand from above to “do something with AI”, and the first real work is finding out what the sentence underneath that actually is. That work is conversation, not typing.

You are looking for the moment someone says something offhand. Someone mentions that they always check one number twice, or that Friday is worse than Tuesday, and there is the whole problem. You will not get that from a requirements document, because the person writing the document does not do the job.

The useful question is rarely “what do you want”. It is “show me what you did yesterday, in order”. People describe their work as they think it should run. Watching it happen gives you the version with the workarounds still in it, and the workarounds are the map.

How much of the day is really spent writing code?

Less than the ads suggest, and it matters more than the hours imply. Code is where the work becomes permanent, so it gets full attention when it happens. But a normal week has more hours of watching, asking and untangling data than of typing. The typing goes fast because the thinking is already done.

There is also a trap in the phrase “production-grade”. An MVP that goes into a live business is production. If someone starts sending real quotes out of your prototype on the second afternoon, it was never a prototype. I now assume anything I put in front of a working person will be used for real by the end of the week, because that keeps happening.

What does integrating a model into a real workflow involve?

Mostly plumbing. Getting data out of a system that was not built to hand it over, deciding what happens when the answer is wrong, and putting the result somewhere a busy person will actually see it. The model call is a few lines and rarely the part that breaks.

The failure mode is not a bad answer. It is a good answer that arrives in a place nobody looks, or three minutes after the person needed it. If a result appears in a dashboard, assume it will not be read. If it appears in the screen where the work already happens, it will.

Does the feedback loop to the product team really happen?

This is the rarest of the four in practice. Everybody agrees it should happen, then the notes about recurring client pain go into a document that no roadmap ever reads. It works when the distance between the person who felt the pain and the person who decides what gets built is short. Usually it is not.

In my own situation that distance is zero, which is an accident of ownership rather than a virtue. When a customer of one of my companies runs into the same wall three times, the person who decides what gets built next is already annoyed about it. That is a structural advantage, not a personal one, and it is worth naming because most Forward Deployed Engineers do not have it.

Why does so much of the work happen in old software?

Because that is where the data lives. The interesting numbers sit in an accounting package from a decade ago, a planning tool nobody dares upgrade, or a spreadsheet that exists on one laptop. Any honest version of this job spends real time getting things out of systems that would rather not.

Old systems are also where the risk sits. Nothing you build is allowed to break invoicing. So a large part of the craft is defensive: assume the export changes format, assume the connection drops halfway, assume the field that was always filled in is empty this once. Reliability here is not elegance. It is being paranoid about the boring parts.

What does a bad day look like?

A bad day is one where you build the right thing for the wrong reason. You finish something that works, people use it, and a week later the underlying process is still broken because the software made a bad routine faster. That is expensive, and you rarely notice it while it is happening.

The other bad day is quieter. You deliver something correct, and nobody uses it, because it asked one extra click of a person who was already behind. That click is the whole project. I have lost more work to a badly placed button than to a wrong algorithm.

When is the right answer to build nothing?

More often than the industry admits. Low volumes, prices negotiated per customer, or a process that only exists because two departments do not talk — in all three cases building something makes the problem faster instead of smaller. Saying so out loud is part of the job, and it is the part people find hardest.

I have written that argument out separately, including what it costs to get it wrong: the answer is that nothing should be built. It is not a modest disclaimer. It is a real answer that gets given.

Is this a new job or a new word?

The work is old. The label is new. People have been sitting between a business and its software since long before anyone used the term, which is why the candidates who fit are experienced generalists rather than new graduates. What changed is that models made the building part fast enough that the understanding part became the bottleneck.

That also explains why the openings are almost always senior. You are being hired for judgement about what should exist, not for output. The same reason explains why there is no certificate for this, and why the skills that decide whether you are any good at it are not the ones printed in the ad.

If you want to see the shape of a finished piece of this work rather than a description of it, here is one with the numbers I can stand behind: a quote that used to take two hours.

Marc Herdes, Almere, 4 September 2026. Building software inside my own companies since 1999.