What is forward deployed engineering? The job, the skills and how it differs from support

Short answer: a forward deployed engineer (FDE) is a software engineer who works at or with the customer to make a product fit their real operations. They write code, configure systems, integrate with the customer's existing tools and carry what they learn back to the product team. The role sits between engineering, consulting and support, and it is defined by direct contact with the people using the software.

Where does the role come from?

The idea became well known through companies selling complex data and operations platforms to large organisations, where the product never fits on day one. An engineer embedded with the customer closes the gap. It has since spread to AI companies, where deploying a model into someone's workflow needs the same close fit.

What does an FDE do day to day?

• Sit with users and watch how work actually happens, not how the process document says it does.
• Configure the product and write custom integrations or small tools around it.
• Clean and migrate customer data, which is often the hardest part.
• Fix issues on the spot, sometimes in production.
• Train staff and write short guides in their language.
• Feed patterns back to the product team: what keeps breaking, what everyone asks for.

How is it different from support, consulting and normal product engineering?

• Support answers questions and fixes known problems. An FDE changes the system to fit the customer.
• Consulting advises. An FDE ships working software.
• Product engineering builds for many customers at once. An FDE builds for one deployment, then helps decide what should become a product feature.

Which skills matter?

• Solid engineering: you will touch databases, APIs, deployment and debugging.
• Listening. Understanding a customer's work takes patience and good questions.
• Communication with non-technical people, including saying no kindly.
• Domain learning: accounting, retail, healthcare, construction. Fast.
• Judgment about scope: knowing which custom request is a real need and which is a one-off that will become a burden.
• Operational care: backups, access control, data safety. You are in someone's business.

What does it look like in small business software?

I do this kind of work on the products on this site. A restaurant owner does not buy "a POS". They buy a way to take orders on a Friday night without chaos. A pharmacist wants batch and expiry handled the way their shop works. Setting OrderRestro up on a server inside a restaurant, or loading stock into KinetiRx, is deployment work: the data, the printers, the staff habits and the failure plan matter as much as the code.

What are the risks of the role?

• Custom work that never becomes product, leaving you maintaining many forks.
• Burnout from context switching between customers.
• Unclear boundaries, where every request becomes your job.
• Pressure to promise things that the product cannot do.

The healthy version has a clear path from customer learning into the product, and a rule for when something is configuration, when it is an integration, and when it belongs in the core.

Is it a good career path?

If you like solving real problems with real people, yes. You learn the business side faster than most engineers. It also protects against the idea that code alone is the valuable part, which links to the question in will AI replace developers.