Forward deployed engineer vs software engineer vs consultant: which one does your business need?

People ask me what a forward deployed engineer actually is. Fair question. My title sounds like something from a defence contractor, and to be honest, that's roughly where it comes from. But for a small business owner, the useful question isn't what the title means. It's this: when you've got a problem to solve, who should you hire?

I'll explain how I see the three roles, where each one is the right call, and where each one tends to go wrong. I'm biased, obviously. I'll try to be fair anyway, because there are plenty of jobs where I'd tell you not to hire someone like me.

What a software engineer does

A software engineer builds software. Usually they're given a spec, a ticket or a product roadmap, and their job is to turn it into working, tested code. Good ones push back on bad specs and care about quality, speed and security.

Palantir, which made the forward deployed role famous, draws the line neatly in a post on its own blog: a traditional software engineer focuses on creating one capability that many customers can use. That's product work. You build the thing once and lots of people benefit.

If you already know what you need built, and it doesn't depend much on how your shop or office runs day to day, a software engineer is the obvious hire. A booking page with a clear design. An API to a supplier. A fix to a slow report. You don't need anyone sitting in your business for that.

What a forward deployed engineer does

The same Palantir post puts it the other way round: a forward deployed engineer focuses on enabling many capabilities for a single customer. Their job adverts talk about embedding with the customer until the problem is yours, and owning the work from the first conversation to shipping.

In plain words, I come into your business, learn how it really works (not how the process document says it works), and then build inside your real systems. Your CRM. Your till. Your WhatsApp inbox. Your spreadsheets that nobody wants to admit run half the company.

The difference shows up in the questions. A software engineer asks "what should the button do?" I ask "who presses it, what were they doing just before, and what happens when they get it wrong?" Then I write the code too. That last part matters. I'm not handing you a report and leaving.

For example, I lead development on the platform a UK repair business runs on: customers, devices, repairs, bookings, payments, invoices and trade-ins all live in one system. You can see the details in my CV. Most of the hard parts there weren't coding problems. They were "how does the front desk actually take a booking on a busy Saturday" problems.

This is also why so much of my work now is AI agents. An agent that answers customers is only useful if it's wired into the real stock, prices and calendar, and has firm limits. I wrote about that in why the system of record should have the final say and where agent guardrails should sit.

What a consultant does

A consultant gives you advice. They look at your business, talk to your people, compare you with what they've seen elsewhere and tell you what to do. A good one saves you from expensive mistakes. They're great at strategy, pricing, regulation, restructuring and picking between vendors.

The catch is that most consultants don't build. You get a plan, a slide deck or a recommendation, and then you need someone else to make it real. That handover is where a lot of value leaks out. The person who understood the problem leaves, and the person who builds the solution never met your staff.

That isn't a dig. Sometimes advice is exactly what you need. If you're deciding whether to open a second branch, you want a consultant, not a developer.

Side by side

Which should you pick?

Here's the rough test I'd use.

If what you really need is a decision, hire a consultant. Should we raise prices? Should we move to a new accounting system? Is this market worth it? Code won't answer those.

If you can write down exactly what you want, and it doesn't touch the way your team works every day, hire a software engineer. It'll usually be cheaper and faster, and that's fine.

If you know something is broken but you can't say what the fix looks like, and it lives in the middle of your operations, that's forward deployed work. Think of staff copying the same details between three systems. Customer messages piling up overnight. A booking flow that works in theory and fails at the counter. Those need someone who'll sit with the problem and also build the answer.

One honest warning. Don't hire an FDE because it sounds modern. If your problem is a clear, small piece of software, you're paying for discovery you don't need. I'd rather tell you that on a call than take on the wrong job.

FAQ

Is a forward deployed engineer just a consultant who codes? Close, but not quite. A consultant's job usually ends at the recommendation. An FDE's job ends when the thing works in production and your team is using it. The building is the point, not a bonus.

Do I need someone on site? Not always. Palantir's FDEs travel a lot. I work remotely from Lahore for clients in the UK and US. What matters is access to your real systems and your people, through calls, screen shares and time spent watching how work gets done.

Is an FDE more expensive than a regular developer? It depends on the job, so I won't throw numbers at you. What I'd say is that the cost to watch is the wrong build. A cheaper developer who builds the wrong thing, or a plan that never ships, often ends up costing more.

Can one person really do all three? For a small business, often yes. You'll get some advice along the way, and plenty of code. But if you need deep legal, tax or financial advice, get a specialist. I'll happily work alongside one.

Talk it through

If you're not sure which one your problem needs, that's normal. Tell me what's going wrong and I'll tell you honestly whether it's a job for me, a developer or someone else. You can see what I build and then book a call or send me a message.