What is forward deployed engineering?

Picture someone who walks into your shop, restaurant, or office and just hangs around for a few days. They stand by the register. They sit in on the Monday ordering call. They ask the person who builds the schedule, "How do you do that?" and then they actually listen to the answer.

A week later they say: "You're copying catering orders from email into a spreadsheet by hand. That's about five hours a week. Here's a form that drops them straight into the sheet." Then they build it, show your staff how to use it, and leave.

That's forward deployed engineering. The name is clunky. The idea isn't.

Where the name comes from

"Forward deployed" is a military phrase for sending people to where the action is. Software companies, Palantir most famously, borrowed it for engineers who work on-site with a customer instead of from a distance. The reasoning was simple. You can't fix a problem you've only read about in a written request.

The small business version is the same. The person building the fix learns your business by being in it, not by reading a form you filled out.

The loop

The work goes in a circle, and it's a short one.

Find the problem. You watch the work and ask people what they did last week. The real time sink is almost never the one the owner names first. (Our guide on finding the problem covers how.)

Build the fix. You make the smallest thing that helps. Usually that's a spreadsheet, a form, a text message that sends itself, or a saved set of replies. A day of work, not a quarter.

Hand it off. You teach the people who'll use it, write down how it works, and make sure the business can run it without you. A fix nobody uses is a failure, even if it works perfectly.

Then you pick the next problem. Some businesses do two or three loops and stop. Others keep going for a year.

Why sitting inside the business matters

When you describe your problem to an outsider, you describe the symptom you've noticed. That's natural. It's also often wrong.

Say a bakery owner asks for online ordering. Someone spends two mornings in the shop and sees that the display case is fine. The mess is custom cake orders. They come in by phone, by Instagram message, and on sticky notes, and twice last month a cake was made for the wrong Saturday. Online ordering for the display case wouldn't have touched that.

You only see that by being there.

What actually gets built

Mostly small, boring things:

• A shared sheet that all catering orders go into, so there's one place to look
• A text that goes out the day before an appointment
• A customer list with the duplicates and typos cleaned out
• A form on the technicians' phones that replaces the paper job notes
• A page of saved answers to the ten questions customers keep asking
• An AI helper that drafts replies for you to read and send

Boring is the goal. Boring gets used.

Who does this work

It might be a professional, a freelancer, a student, a volunteer, or you. The skill isn't programming. It's paying attention, asking plain questions, and building small. The most technical thing in a typical project is a spreadsheet formula.

When it's the wrong fit

Skip it if you already know exactly what you need and it's a standard product. If you need a point-of-sale system, buy one. Nobody needs to watch you work to figure that out.

It's also a poor fit if you want a giant system built over a year, if you can't let anyone see how the work really gets done, or if nobody on your team will try anything new. The last one is fixable, but it takes longer than the building does.

To see how this compares with other ways of getting help, read forward deployed engineer vs. agency vs. software subscription. If you'd like to know what the first few weeks look like, start with what to expect.