FDE Engineering Fundamentals
Discovery, solution architecture, POCs and productionisation
The engineering craft of forward deployed work: customer discovery, technical discovery, solution architecture under constraints, rapid prototyping, customer POCs, integration, security reviews and stakeholder communication.
Who this series is for
This series is for engineers working directly with customers to deploy AI systems inside their organisations, a role often called forward-deployed engineering. It assumes solid technical depth in RAG, agents and production systems. The hard problems here are only partly technical: unclear requirements, messy enterprise data, security reviews, and turning a promising prototype into something the customer's team can own.
What each chapter covers
- Discovery & Requirements covers running discovery sessions, finding the workflow where AI changes an outcome that matters, and writing success criteria the customer agrees to before you build.
- Solution Architecture covers designing within enterprise constraints such as SSO, data residency, network boundaries and existing systems, and documenting trade-offs so decisions survive handover.
- Prototyping & Productionisation covers building a prototype that proves the riskiest assumption first, then hardening it with evaluation, monitoring and runbooks.
How to approach it
Pair each chapter with one of the FDE scenarios on this site, which put the same decisions under realistic constraints. If you are preparing for FDE interviews, the discovery chapter is the most frequently tested. The series is roughly nine hours.
Skills you'll gain
Prerequisites
Chapters
Customer and technical discovery — the most undervalued FDE skill.
Designing AI systems under real customer constraints.
From POC to production — the hardest journey in FDE work.
Rank candidate AI use cases by value, feasibility and risk before committing a team to one.
Write the scope, definition of done and success criteria before building, so the proof of concept ends in a decision.
Find out early whether the customer's data can support the system, before the build depends on it.
Treat security as a stakeholder: find the real requirement, show the data flow, and get to yes.
Build an evaluation set with the customer's experts so quality is a number both sides trust.
Give agents their own identities, approval tiers, audit logs and a staged pilot before widening their autonomy.
Report progress executives read, hand over a system the customer can run, and decline work that should not be built.