FDE Műhely
HU Let's talk

Forward Deployed Engineering

Intelligence got cheap.
Deployment did not.

Your competitors can buy the same model you can. The difference will be who can get it into their own processes. That's what we do: we come in, map how the work actually runs, and hand over a system running in production, built on the ERP and CRM you already have.

Book a discovery How we work
The same four-step process twice: as documented, and as it actually runs The top row shows four clean steps. The bottom row shows the same steps, each with exception branches hanging beneath it: senders in different formats, data buried in PDFs, manual retyping, drifting columns, double entry and undocumented approvals. AS DOCUMENTED Email arrives Copied to a spreadsheet Keyed into the ERP Approval AS IT ACTUALLY RUNS Email arrives 40+ senders, no two alike the number is inside a PDF Copied to a spreadsheet retyped by hand columns drift out of line Keyed into the ERP entered in two systems Approval "Eve already signed this" no consistent subject line

AS DOCUMENTED

  1. Email arrives
  2. Copied to a spreadsheet
  3. Keyed into the ERP
  4. Approval

AS IT ACTUALLY RUNS

  1. 01

    Email arrives

    • 40+ senders, no two alike
    • the number is inside a PDF
  2. 02

    Copied to a spreadsheet

    • retyped by hand
    • columns drift out of line
  3. 03

    Keyed into the ERP

    • entered in two systems
  4. 04

    Approval

    • "Eve already signed this"
    • no consistent subject line
The first four steps of a real accounts-payable process at a mid-sized Hungarian company. The top row is what the process document says. The bottom row is what your colleague faces on Monday morning. An FDE's work starts with the question of which branch anyone has written down at all.

The problem

Pilots don't fail on the model. They fail on the process.

The MIT Media Lab's NANDA study (The GenAI Divide: State of AI in Business, 2025) surveyed 153 leaders and reviewed more than 300 public deployments. It found that 95% of generative AI pilots produced no measurable business return. It puts the cause down to organisational adoption rather than model capability.

Ask someone how their process starts and they'll say "an email arrives". The reality is it arrives from forty senders, no two formatted alike, half the time the number that matters is inside a PDF, and the rule for where each case gets routed lives in one colleague's head. They never wrote it down, because nobody ever sat next to them for eight hours and asked.

So the first step here is always the same: someone goes in, sits with the team, and watches how the work happens.

  • We work in three phases: discovery, evals, deployment. In that order, with none of them skipped.
  • We don't migrate systems. We build on what already runs at your company.
  • Every step is logged. If you can't see what the system did, you won't trust it.

The FDE's judgement

Not every step needs a model

The most expensive mistake is handing everything to the model. Most of the work is solved better, cheaper and more reliably by deterministic software. An FDE's job is to decide, step by step, which is which. Same process as above, redesigned:

  • Deterministic
  • Agent
  • Human
  • Exception
  1. 01

    Intake and normalisation

    Unpack attachments, drop duplicates, land on one format. This can be done without a model, so it is.

  2. 02

    Extraction

    From PDFs, screenshots, forwarded threads. Judgement belongs here, because no two senders are alike.

  3. 03

    Schema validation

    Required fields, totals, vendor master. If it fails, it doesn't move on.

  4. 04

    Matching and coding

    Tie to the purchase order and delivery note, propose a cost centre, flag uncertainty.

  5. 05

    Approval

    The finance clerk sees the proposal and the source on one screen. They press Enter, not the model.

  6. 06

    Write back to the ERP

    Through the existing API. We don't migrate systems, we build on them.

  7. 07

    Exception queue

    Whatever the system won't finish queues up for a named person, with a reason attached.

The process

Discovery → Evals → Deployment

Each phase is a prerequisite for the next. Without evals you don't know whether it works; without discovery you don't know whether you're building the right thing at all.

  1. 01

    Discovery

    2–4 weeks

    We sit with the team and record how the work actually happens, not what the process document claims. You get an operating map, an ROI matrix of what is worth automating and what isn't, and a concrete build plan.

    • Operating map, step by step
    • Every exception and failure branch
    • ROI matrix: what to automate, what to leave
    • Architecture and estimate
  2. 02

    Evals

    2–3 weeks

    Nothing goes live before it is measured. We assemble a golden dataset from your own historical cases and run the system against it. You get a number for where the system stands, and the exact place the errors come from.

    • Golden dataset from your own cases
    • Run-by-run measurement report
    • Failure modes, categorised
    • The threshold: what can run unattended
  3. 03

    Deployment

    4–8 weeks

    We build on what you already run. The system starts in shadow mode alongside your team, then earns autonomy one category at a time. Every step is logged and reviewable. If you can't see what it did, you won't trust it, and you'd be right.

    • Shadow mode, then staged rollout
    • Full audit trail per step
    • Alerting and SLA monitoring
    • Handover, docs and training

What you can hire

One engineer, a team, or just the discovery

Embedded FDE

One senior engineer with your team two to five days a week. They map the process, they build it, and they own it in production.

Details

Discovery only

Fixed-price, two to four week assessment of one department. You get an operating map and an ROI matrix. No obligation to continue.

Details

Full team

An FDE, a data engineer and an eval owner on one programme. Worth it when you're taking several processes live at once.

Details

Writing

What we wrote down along the way

All articles

Frequently asked questions

How are you different from a management consultancy?

A consultancy hands over a deck, we hand over a working system. Discovery is our first phase, and the same engineer who mapped the process then builds it. That leaves no handover gap between the people who understood the problem and the people who wrote the code.

Do we have to replace our ERP or CRM?

No, we do the opposite. If someone spent two years and a large budget rolling out a system, the last thing they need is another migration. We build on the APIs of what you already run, and connect those systems to each other.

How long before we see anything?

Two to four weeks after discovery starts we can give you a concrete number for how much time and money sits in the process. The first workflow running in production is typically live in month three, and visible in shadow mode well before that.

Which model do you use?

Whichever gives the best accuracy for the money on that specific step, and we measure it rather than guess. We build so the model stays swappable: your own eval set remains the basis for the decision even when something cheaper or better ships six months from now.

What happens when the system gets it wrong?

That's what the whole design is for. A process can go right one way and wrong several hundred ways. We design the exception branches as carefully as the happy path: anything below the threshold queues up for a human with the reason attached.

Can we hire a single FDE long term?

Yes, and it is the most common arrangement. One senior engineer embeds with your team two to five days a week and drives deployments from the inside. Details on the pricing page.

Let's start with one process

Tell us which department burns the most manual hours. We'll come back with a concrete proposal for what discovery would look like at your company. We don't send templates.

Get in touch hello@fdemuhely.hu