An engineer inside your company. Until AI actually works.
Anyone can sell you the best tool, hand you a login and disappear. An FDE stays: sits with your team, learns how your business works in practice, connects systems, data and agents, and delivers something running in production.
They land in the middle of your operation with a single mission: make the technology work — with your data, your systems and your people, not the demo's.
What an FDE is
Forward Deployed Engineer: an engineer deployed in the field. It's the most sought-after role in tech today, and it sounds more mysterious than it is: a technical person who works inside your company until what was bought, promised or imagined actually works.
Sits in
Connects
Builds
who
connects it?
The problem
Your company wants to use AI. It isn't missing the tool: it's missing someone to make it work with what it already has.
“The data is in one place, the system in another”
And the system is from 2009, has no API, and nobody dares touch it.
“The business runs on a spreadsheet”
It's called final_FINAL_for_real, one person understands it, and it's the one really in charge.
“They gave us a login and wished us luck”
The vendor sold the license and vanished. The tool is paid for and nobody uses it.
“It worked in the demo”
The pilot looked great. Taking it to production is a whole other project, and nobody owns it.
The fourth is the most expensive: the money is already spent, and what was bought never reached the hands of the people who were going to use it.
Between the demo and your company there's a gap
And someone has to close it. That gap is an FDE's job, and it's almost the whole job.
| In the demo | In your company | |
|---|---|---|
| Data | Clean, in one place | Across four systems, a spreadsheet and someone's inbox |
| Systems | A modern API | A 2009 system with no API, and another that's “off-limits” |
| Users | One, with every permission | Forty, with different roles, and an auditor |
| Cases | The happy path | The exceptions, which are half the work |
| Afterwards | Nobody | Someone has to maintain it on Monday |
No tool closes this table on its own. It takes someone who knows both columns and sits on the right-hand side.
Who it's for
You don't need a big technical team, or any technical team at all. You need something that should be running and isn't.
You bought an AI tool and nobody uses it
The license gets paid every month. The problem isn't the tool: it's that it was never connected to how your people work.
You have a pilot that won't make it to production
It worked in the presentation. What's missing is the boring part: permissions, exceptions, real data and someone to keep it running.
You're being asked to “do something with AI”
The board wants it, and someone already sold you the fear of being left behind. You need a first real, measurable case, not another presentation.
Your tech team is stretched thin
They know what should be done, but between operations and whatever is urgent, integration never becomes a priority.
An entire process lives in a spreadsheet
It works because one person maintains it by hand. The day they're out, so is the process.
A legacy system that can't be replaced
You have to live with it. AI has to read from it without breaking anything that already works.
If what's missing isn't hands but someone to decide and review (architecture, vendors, who to hire), that's Fractional CTO.
What it isn't
The word is trendy, and anyone who was selling something else yesterday uses it now. This table says what you're buying here, and what you're not.
| It isn't | It is | |
|---|---|---|
| Delivery | A consultancy that leaves a PDF of recommendations | Something running in production, with real users |
| Tools | A license reseller | Agnostic: if what you already paid for works, that's what gets used |
| Team | A replacement for your tech team | Works with your team and hands everything over to them |
| Timeline | An endless pilot | A case with a date, a metric and a handover |
| AI | An agent that changes things on its own | AI proposes; a person on your side approves |
An FDE who doesn't hand over becomes a dependency. That's why the handover isn't an optional phase: it's part of every case.
How it works
Five steps per use case. What comes out isn't deliverables: it's something someone uses on Monday.
Sit with the team
Learn how the business works in practice, not on the org chart.
Pick just one
Small, measurable, and something someone will actually use.
Systems, data and agents
With scoped permissions: read-only, unless decided otherwise.
With real users
And a before-and-after metric, measured with your data.
Your team runs it
Documented and tested. The FDE moves on to the next case, or leaves.
A bit of each, with one difference
Part developer, part architect, part consultant. The difference is that they build: nothing counts as done until it runs.
Developer
Writes the integration, the connector and the agent. Doesn't farm them out.
Architect
Decides how it fits with what you already have, so you don't have to throw it out in six months.
Consultant
Understands the process and the people who run it, which is where AI projects get stuck.
Everyone does their part, and nobody ties it together
- The consultant diagnoses and leaves
- The vendor installs and leaves
- The internal team inherits something it didn't choose
One person is accountable for making it work
- From understanding the problem all the way to production
- With the internal team alongside, not afterwards
- And with the handover as part of the job
What stays on your side, from day one
An outsider working inside your systems is scary, and it should be. The answer is rules, not trust.
The code, in your repositories
From the first change. There's no “vendor” version you have to ask for at the end.
Author isn't approver
No change goes in without a person on your side approving it. Not even the ones the AI proposes.
Named, revocable access
Read-only by default. Switch off the user and everything keeps running.
The metric, measured with your data
Before and after the case, with criteria declared before starting.
The case · a 4-year-old fintech
A vendor that was already gone, a developer with an exit date, and the knowledge spread across four silos. One person, leveraged by AI, working inside:
The developer left on the planned date and operations carried on without interruption. That's what you're buying: it keeps working when whoever built it is gone.
Anonymized reference case, the same one on brain.placedium.com: no client name, no amounts, no third-party data. The figures are kept exactly as measured.
How it starts
Something small and verifiable first. Only once one case is running do we talk about the next.
Field week
A map of systems and data, and the first case chosen, with its metric.
Per use case
All the way to production, with a date and a metric agreed before starting.
Included, not an extra
Your team runs it. If another case follows, it starts again in the field.
If the field week shows that what's missing isn't an FDE, you'll hear it right then, and the map is yours anyway.
Companies and projects I've been part of
Over 25 years in fintech, banking, retail, media, streaming and government: the companies I worked at, and the projects and clients that came through my teams.
The names belong to their owners; the circles are initials, not logos. In blue, the companies I worked at; around them, projects and clients.
Connect.
Build.
“Between ‘it works in the demo’ and ‘it works in your company’ there's a gap. Someone has to close it.”
Let's talk. One case.
Tell us what should be running and isn't. One short conversation is enough to know whether an FDE is the answer.