Is a forward-deployed engineer a consultant?

No. They build and ship the software, after spending the first days learning how the work really runs.

Does the engineer need to be on site?

Often for the first days, at the order desk or on the floor. After that, most of the work is remote.

What a forward-deployed engineer does in your business

The expensive part of software is not writing code. It is finding out what to build. Here is how putting an engineer inside a business, instead of handing them a brief, changes what gets built and how fast.

Most software projects that go wrong go wrong in the same place: the gap between what a business actually does and what the people building the software think it does.

The brief says automate order entry. The order desk knows that two customers still fax, one always sends last year's part numbers, Friday orders ship from the other warehouse, and anything for the big account needs the sales manager's eye before it goes in. None of that is in the brief, because nobody writing the brief thought of it as unusual. It is just how the work runs.

Large software companies solved this problem for their biggest customers years ago. Instead of sending a salesperson with a questionnaire, they send an engineer to sit inside the customer's operation, learn how it really works, and build what is needed on the spot. The role is called a forward-deployed engineer. We work that way for businesses that will never have a software team of their own.

What it looks like in practice

At a manufacturer, the engineer spends the first days at the order desk, at the estimator's elbow and on the floor at shift change. They follow one real order from the customer's email to the truck leaving, and they write down every screen it touches, every spreadsheet that quietly holds something together, and every time somebody says we always check that by hand.

At a retailer, it is the returns bench, the stock room, the customer service inbox and the weekly buying meeting. The question is the same: where does a person spend time moving information from one place to another, and what goes wrong when they are away?

Sit with the team Real time with the people who do the work, during the work. Not a workshop in a meeting room, and not a survey.
Map how it really runs Every step, every system, every exception, written down in plain words the team agrees with.
Pick one process The one that happens often, is mostly retyping or chasing, and touches money or customers.
Ship it in weeks A first useful version, running on real work, while the engineer is still close enough to watch it being used.
Stay close The same engineer keeps improving it with the people who use it, then moves to the next process.

Why it is faster, not slower

It sounds slower to spend days watching before building anything. In practice it is the fastest route we know, for one reason: rework is what makes software projects long. A feature built from a misunderstood brief has to be built twice. An exception nobody mentioned turns into a month of fixes after launch.

An engineer who has watched the order desk for two days builds the right thing first. They know which fields matter and which are noise, which customer is the hard one, and which step the team will refuse to give up. They also know who to ask when something is unclear, and that person is a few metres away rather than three emails deep.

An engineer who has watched the order desk for two days builds the right thing first.

Where AI comes in

We build with modern AI tools at every step, and it is a large part of why a first phase arrives in weeks. AI reads the sample orders, process notes and spreadsheets the engineer collects and drafts a first map of the process. It drafts the routine parts of the code and generates tests from real examples, including the odd ones.

That speed only pays off because the engineer knows the business. AI output that looks right is not the same as output that is right, and the person who can tell the difference is the one who watched the work happen. Every piece is designed and reviewed by an engineer who can explain it.

What it is not

It is not a consultant who leaves a slide deck and a recommendation to buy something. It is not a team of strangers working through a ticket queue in another time zone. And it is not a promise to replace your ERP, your store platform or your accounting system; most of the time those are fine, and the problem is the gaps between them.

It is one person you know by name, who knows your business, with a team behind them for the parts that need more hands.

How to tell if it fits your business

This way of working suits businesses that already run on a set of systems and feel the strain in between: a manufacturer whose order desk retypes PDFs, a retailer whose stock is never quite right across the shop and the website, a distributor whose orders live in reps' inboxes. If your team can name the task that eats their week, it fits.

It suits a business less well if what it needs is a single off-the-shelf tool switched on, or a large platform replacement with a fixed specification. We will say so if that is the case.

Questions people ask

Is a forward-deployed engineer a consultant?: No. They build and ship the software, after spending the first days learning how the work really runs.
Does the engineer need to be on site?: Often for the first days, at the order desk or on the floor. After that, most of the work is remote.

Start with one process. Tell us which task your team retypes or chases every day. We will tell you honestly what a first phase would look like, and whether we are the right people to build it.

Canonical URL: https://ugibo.com/blog/forward-deployed-engineering