FDE Műhely

Forward Deployed Engineering · Budapest

Intelligence got cheap.
Deployment did not.

Your competitors can buy the same model you can. The difference won't be who has access — it 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.

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
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 widely cited MIT survey found that the overwhelming majority of generative AI pilots never reach production. Not because the model is bad — because nobody mapped where it was supposed to go.

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 we don't start by building. We start by going and looking.

  • 3 phases: discovery, evals, deployment — in that order, none skipped
  • 0 system migrations. We build on what already runs at your company
  • 100% of steps logged. If you can't see what it 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. No model involved — none is needed.

  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 doesn't vanish — it queues up, with a reason.

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 don't get an opinion that it 'looks good' — you get a number, 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

Frequently asked questions

How are you different from a management consultancy?

A consultancy hands over a deck. We hand over a working system. Discovery isn't our deliverable, it's our first phase — and the same engineer who mapped the process then builds it. There is 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 doesn't disappear, it 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 — not a template.