Forward deployed engineer: four AI and fintech builds, from first call to production
A forward deployed engineer goes to the customer, finds the problem that matters, and builds the software that fixes it inside the customer’s own systems, all the way to production.
The role was invented at Palantir. It is now one of the fastest-growing jobs in tech. On Indeed, postings for it in April 2026 were roughly 729% higher than in April 2025, according to Business Insider. The reason: getting AI to work inside a real company turns out to be a deployment problem, not a model problem.
I’m Mo Tawfik Khalifa, chief product officer and forward deployed engineer at Instruxi. I lead product and the teams, and I still build: I come from coding and design, and I ship with AI at every step. Here are four builds from the field. I built them, but the clients can’t be named under NDA.
What is a forward deployed engineer (FDE), and what do they do?
A forward deployed engineer sits between the customer and the product team. They write production code in systems they did not build, scope problems the customer cannot yet put into words, and explain trade-offs to executives who do not care about the tech stack. In practice it is five steps, in this order.
And round again. How I work on every build below. Step three is the one most teams skip.
1. Guardrails for AI coding agents
The problem. Teams wanted AI coding agents working with real access: the shell, git, cloud credentials, a company card. One bad loop can burn a budget in minutes. One confident command can wipe a folder or push over a colleague’s work. “Be careful” in a prompt is not a control.
What I built. A free, source-available guard that sits between the agent and its tools and answers one question before every action: is this allowed? Each call gets one of three answers: allow, deny, or stop and ask the person.
- Spend caps per minute and per session. Hitting the per-minute cap pauses the agent and asks you. It does not throw the work away.
- Loop detection. An agent repeating the same failing step gets stopped.
- Command rules. Piping a script from the internet into a shell is denied outright. Deleting folders, force-pushing, touching credentials and deploying stop and ask first.
- A record you can prove. Every decision goes on a hash-chained record, so afterwards you can show exactly what the agent was and was not allowed to do.
- Local and locked. It runs on the developer’s own machine, plugs into agents over MCP, and none of its agent-facing tools can loosen a limit.
Try it
Pick what the agent tries. The guard answers before it runs.
The agent wants toEach pick prints on the guard's record.
$ waiting for the agent
Every answer is stored with a fingerprint of the entry before it.
Result. Published free and source-available, with a live dashboard and a one-line install. The rule I held to: the agent can never talk its way past its own limits.
2. A credential passport for clinicians
The problem. Doctors, nurses and paramedics prove the same licences again for every new hospital, agency and shift. Every time means forms, scans and weeks of waiting while someone checks the licensing board by hand.
What I built. A mobile app for iOS, Android and the web where a clinician’s licences and certifications live in one encrypted vault, verified at the source.
- Identity check built into sign-up.
- Licences verified against the issuing authority, with an alert before one expires.
- Sharing that gives away only what you choose. Tick the fields, name the one recipient, pick how long the link lives, from one hour up to 30 days or never, and revoke it any time.
- A portal for the verification company to publish new credential types, and a checkout to order new checks.
- Underneath, a governance layer that decides who can see what, and decentralised encrypted storage for the files.
Try it
Share one licence with a hospital, and only the parts you choose.
Sample data. In the real app each licence is checked against the board that issued it.
Result. Through QA and submitted to App Store beta, with the publishing portal in the verification team’s hands.
3. Digital dollars and gold for community banks
The problem. U.S. community banks are watching deposits leave for stablecoins and crypto apps. Their own trade body puts the deposits at risk from yield-bearing stablecoins at $1.3 trillion. Access is easy to buy now: large exchanges already resell custody and stablecoin payments to thousands of banks. What a bank cannot buy off the shelf is the decision layer: who passed identity checks, who can send, mint or redeem, what the limits are, and a record an examiner will accept.
What I built. Three working pieces, for three different conversations.
- A bank-in-a-box for a listed gold company. A white-label app where a bank’s customers hold dollars, stablecoins and tokenised gold in one balance. The demo is a money path: press send or buy gold and watch the value travel from the customer to the bank, through a checkpoint, onto the payment rails and into the ledger. The checkpoint opens or holds the money with a plain-English reason, from 11 ordered rules with three outcomes, including “unavailable” when a fact it needs has gone stale. The technical record sits one tap away, never in the customer’s face.
- A partner-bank app, explained for bank people. Customers fund, invest in and track digital assets from the bank they already trust. They keep the keys to their own wallet, the bank chooses what is on the menu, and every move is checked before it happens. It ends in a three-step pilot.
- A cross-border payments pitch for a network that settles between member banks in seconds: an interactive page where you switch one part off and watch the payment fail, so the buyer sees what each piece is for.
Try it
Press an action and follow the money. The checkpoint decides before anything moves.
Customer account
Example customer, statement pageRouting slip
each desk stamps it as the money passes- 01Customerpresses send or buy
- 02Their bankthe app they already trust
- 03Checkpointidentity, limits, who it goes to
- 04Payment railsdollars, stablecoins or gold
- 05Ledgerthe record an examiner reads
Pick an action below.
Teller slips
Entries
newest first| No. | Particulars | Amount | Checkpoint |
|---|---|---|---|
| No entries yet. | |||
Pick an action to see the checkpoint’s record.
Example accounts and rules. A real bank sets its own limits, and the checkpoint checks them in order.
Result. Each one turned a slide-deck conversation into something a bank could press. The money-path and partner-bank demos each ship with a test script that checks every claim on the page, so the numbers on screen never drift from the engine behind them.
4. A street of homes, read from the blockchain
The problem. A client turns rented homes into tokens that back a loan. On their test network every piece existed: house, token, vault, loan, rent. Nobody outside could see how a dollar of rent moved through them, and the team could not see where the live data and the app disagreed.
What I built. A working prototype that reads the client’s live test network and draws every home as a plaster model on a 3D street, each one built from its own listing: storeys, floor area, garage. Hover over a house to see the real photo, or collect a month of rent and follow the coins.
- A scroll journey from house to token to vault to loan to rent.
- Four break-it gates. Switch off the title check, the valuation, the rent feed or the holder check and see what fails.
- The client’s own yield formula as sliders.
- Every token explained in one plain sentence.
- A ship list of fixes, each with screenshot evidence, and a check script that fails the moment the client fixes one, which is the signal to update the page.
Try it
Six rented homes, each one a token. Collect a month of rent, then switch a check off and see what breaks.
Ref. tokens #1 to #6
Agent’s note
Hover or tap a house to see its token.
Four break-it gates
Switch a check off and see what breaks.
House, token, vault, loan, rent
Scroll through, or pick a step.
-
Six rented homes. Home 1: 3 bed, rent $1,550/mo, value $172,000.
-
Each one a token: home 1 is token #1.
- Title check
-
6 homes in the vault.
-
$540,000 can be borrowed, half the value.
- Valuation
- Holder check
-
$9,600 rent a month. 80% of the month’s rent goes to lenders. The rest stays for upkeep.
- Rent feed
Illustrative numbers. The real build reads every home, token and loan live from the client’s test network.
Result. One page that explains the product to an investor in a minute and doubles as a bug list for the engineers.
What the four builds have in common
- Start with the customer’s problem in their words, not with the product.
- Put a check in front of every risky move: an agent command, a shared licence, a payment, a loan.
- Give a plain-English reason for every decision, and keep the technical record one tap away.
- Build demos the buyer can break, not slides they sit through.
- Ship a test with every claim, so what the page says stays true.
How fast is demand for forward deployed engineers growing?
Fast. Two dated numbers, from two sources:
- More than 800% growth in forward deployed engineer job postings from the start of 2025 through September 2025, reported by the Financial Times and covered by Fast Company.
- Roughly 729% year on year: Indeed’s postings for the role in April 2026 against April 2025, shared with Business Insider.
Both reports tie the growth to the same need: companies bought AI, and someone has to make it work inside their own systems.
Forward deployed engineer vs product manager vs solutions engineer vs consultant
I do two of these jobs at once: I’m chief product officer and forward deployed engineer at Instruxi. So this is how I tell them apart from the inside.
- Forward deployed engineer. Works inside one customer’s systems and writes the production code that makes the product run there. Stays until it runs, then feeds what they learned back to the product team.
- Product manager. Decides what to build next and why, across every customer. The output is priorities and specs, and the engineers write the code.
- Solutions engineer. Works before the sale. Shows a buyer how the product fits, runs demos and proofs of concept, answers the technical questions, then hands over at signature.
- Consultant. Studies the problem from outside and recommends what to do. The output is a report and a plan, usually independent of any one product, and someone else builds it.
- Fractional CPO. Runs product and the product team part-time: one priority list, the team, and how it ships. That is the fractional CPO work.
The quick test: if your customers cannot get the product working in their own systems, or you need code shipped inside a client’s stack, you need a forward deployed engineer. If you do not know what to build, a product manager. If you need a demo to win a deal, a solutions engineer. If you want an outside plan before you spend, a consultant. If nobody runs product, a fractional CPO.
The quizFive questions, one answer
Who do you actually need?
Five questions about where you are. See which role you need, and what they do in week one.
| Role | What they do | Writes production code | When they come in | What you have at the end |
|---|---|---|---|---|
| Forward deployed engineer | Builds your product into one customer's systems and stays until it runs | Yes, inside the customer's stack | After the sale, sometimes building the prototype that wins it | Working software in the customer's production |
| Product manager | Decides what to build next and why, across all customers | Rarely | Before and during every build, full-time | A ranked roadmap and clear specs |
| Solutions engineer | Shows a buyer how the product fits and answers the technical questions | Demos and proofs of concept | Before the sale, deal by deal | A demo the buyer believes, and a signed deal |
| Consultant | Studies the problem from outside and recommends what to do | Usually not | Before you commit money, for a fixed project | A report and a plan your team carries out |
| Fractional CPO | Runs product and the product team, part-time | Sometimes | When nobody owns product, ongoing | One priority list and a team that ships to it |
The first and the last are the two I do: forward deployed engineering and running product. The part-time version is here: fractional CPO.
How do you become a forward deployed engineer?
I came through three eras, and each one gave me part of the job.
- Live broadcast systems. I started as a broadcast engineer at the BBC and Channel 4, then worked on live Formula 1 coverage, as technical and transmission manager at the Winter Olympics, as a technical manager at Sky and as a streaming manager at Amazon. Live TV teaches you to work inside systems other people built, to draw the workflow before you build it, and to ship things that cannot fail in front of an audience. More in how live TV and streaming work.
- Immersive 3D. I turned engineering models into live Unreal and Unity environments, real-time digital twins for the FIFA World Cup in Qatar, Expo 2020 and SEVEN. Then I led teams: technical director at Sensorium, VP production at Expo 2020 Dubai, VP delivery at Napster with 24 developers, designers and producers. That is the customer-facing half: taking a client’s own data and making something they can walk through. More in virtual stores, live shows and 3D worlds.
- AI and fintech. Blockchain work at Theta Labs and PLAYERUNKNOWN Productions, head of growth at OKX, and now Instruxi, where I ship the four builds above with AI at every step. This era adds the hardening: identity, permissions, limits and a record you can prove. More in can one person with AI do a whole team’s work.
You do not need my route. You need what it added up to. If I were starting now, I would do it in this order:
- Ship one real product on one stack. Something people use, that you deployed and kept running.
- Work inside systems you did not build. Integrations, legacy code, other people’s data and permissions.
- Get close to customers. Support, delivery, implementation or solutions roles all count.
- Learn to write it down. A one-page scope with a demo date, and trade-offs in plain English for someone who does not care about the stack.
- Build with AI in the loop, and harden what you build. Fast prototypes are easy now. Production is the skill.
- Show your work. Demos people can press beat a CV line.
The skills, concretely
- One backend language to production standard, Python or TypeScript, plus enough front end to put a working screen in front of a customer.
- APIs, webhooks and sign-in: OAuth, single sign-on, API keys and how to scope them.
- Databases and SQL, and reading a data model you did not design.
- Deployment: containers, CI, cloud, logs and monitoring.
- LLM work: prompts, tool calling, AI agents, MCP, and tests that catch a bad answer before a customer does.
- Security basics: least privilege, secrets handling, audit trails.
- Scoping: turning “we want AI” into one problem, one owner and one date.
- Explaining: a trade-off in two sentences to an executive, and the same trade-off in detail to their engineers.
- One domain deeply. For fintech that means identity checks, payment rails, ledgers and what a regulator will ask to see.
Questions people ask
What does FDE stand for?
FDE stands for forward deployed engineer: an engineer who works inside the customer’s team, on the customer’s systems, until the product works there. It is also searched as “forward deployment engineer”.
What is the difference between a forward deployed engineer and a solutions engineer?
A solutions engineer shows how the product fits and helps sell it. A forward deployed engineer builds production software inside the customer’s environment and stays until it runs. Many forward deployed engineers start where a solutions engineer stops.
What is the difference between a forward deployed engineer and a sales engineer?
A sales engineer runs demos and answers technical questions during the sale. A forward deployed engineer writes and ships the code after the contract, and often builds the prototype that wins it.
What skills does a forward deployed engineer need?
Writing production code in systems you did not build, scoping vague problems, explaining trade-offs to executives, and shipping fast without breaking security. In AI work, add LLM integration, AI agents and MCP, data access and permissions, and deployment.
How fast can a forward deployed engineer ship a prototype?
Days, with AI in the loop. The slow part is hardening: identity, permissions, limits and an audit trail. Skip it and the prototype stays a demo.
What is the difference between a forward deployed engineer and a product manager?
A product manager decides what to build for all customers. A forward deployed engineer builds it into one customer’s systems and writes the code. Good forward deployed engineers feed what they learn back to the product manager.
What is the difference between a forward deployed engineer and a consultant?
A consultant recommends what to do and hands over a plan. A forward deployed engineer ships the working software inside your systems and stays until it runs.
Is a fractional CPO the same as a forward deployed engineer?
No. A fractional CPO runs product and the product team part-time across the company. A forward deployed engineer works on one customer deployment at a time. I do both kinds of work, and the fractional CPO page covers the part-time product role.
How do I become a forward deployed engineer?
Ship one real product, then get good at working inside systems you did not build, close to the customers who use them. Add plain writing, AI in the loop and the hardening work: identity, permissions, limits and an audit trail.
Is forward deployed engineering in demand?
Yes. Postings grew more than 800% from the start of 2025 through September 2025, per the Financial Times, and Indeed’s postings for the role in April 2026 were roughly 729% above April 2025.
Do you take on forward deployed work?
Yes. If you have an AI or fintech problem that needs someone to sit with your team and ship it, write to m@tawfik.tv.
