The Six Parts Every Engine Is Made Of

“Custom software” is a frightening phrase, and it should be. It sounds like a blank page, an open-ended bill, and a thing you cannot picture until it either works or does not.

So here is the part nobody explains before you have already signed something. An engine that runs a business process is not a blank page. It is assembled from six parts, and it is the same six every time.

Knowing them is useful even if you never buy anything, because it gives you six specific things to ask about instead of nodding along to a demo.

The six

• The intake. Where work comes in — a form, an email, an upload, a phone call, a message from another system. One door, so nothing arrives somewhere nobody is watching.
• The router. Decides where each thing goes. Is this urgent, is it a warranty job, is it a customer we already have, does it need the person who handles the tricky ones.
• The workers. The steps that actually do it — read the document, pull the fields, price the lines, build the record, send the thing.
• The gate. Where it stops and asks you. The one place a human decision is genuinely required, with everything already prepared.
• The log. Everything it did, in order, replayable. What came in, what it decided, what it sent, who approved it and when.
• The panel. Where you watch it run. How many times it ran this week, how many it handled alone, how many it stopped for you.

Why this matters commercially

Because it answers the question that decides whether you are being quoted for a project or a product: is this off-the-shelf or bespoke?

The honest answer is both, in a specific way. The parts are standard. The wiring is yours.

The intake, the router, the gate, the log and the panel are the same machinery for a plumbing firm as for an accountancy practice. What differs is what the workers do and where the gates sit — and that is the part that has to be built around how you actually run. It is why an engine takes weeks rather than months, and it is also why nobody can hand you one out of a box.

The two parts people skip, and what it costs

If you look at a proposal and only four of the six are described, it is almost always these two that are missing.

The log. Skipping it is invisible on day one and expensive on the first bad day. Without a record of what the system did and why, a disputed invoice, a missing order or a wrong decision becomes an argument rather than a lookup. Ask to see the log before you agree to anything — not a description of it, the actual screen.

The panel. This is the one you touch daily, and it is the difference between owning something and hoping something is happening. Not a business dashboard full of charts. An engine dashboard: it ran this many times, it handled this many on its own, it stopped for you this many times.

That last one deserves emphasis because it is a trust instrument as much as a feature. A number you can look at every morning is what stops an automated process from being a black box you are afraid to touch.

The gate is the part that decides whether you can trust it

Every fear people have about automating operations lives in one question: what if it does something stupid at scale?

The gate is the answer. Money, records, permissions and anything a customer sees are exactly where a person stays in the loop. The engine does the assembly and stops; you decide; it continues. It proposes, you dispose, every run is logged.

Which also means a proposal that describes no gates at all is not a more advanced system. It is one where nobody has thought about what happens on the day it is wrong.

Why I care about the log more than most people

I build open-source tooling for governing AI agents in my own time — the main one is a kernel that judges work by evidence and executable checks rather than by how confident a model sounds, and it is genuinely pre-release, with known gaps written down in its own README rather than hidden.

The thing that project taught me transfers directly here, so take it and skip my version of learning it. Absence of evidence has to be a failure, not a default pass. A system that cannot show you what it did should be treated as a system that did not do it — because the alternative is trusting a report instead of checking an artefact, and reports are where the expensive surprises hide.

That is not a technical preference. It is the same instinct that makes you keep receipts.

Use the six as a checklist

Take whatever you are being sold — a build, a platform, an automation project — and ask one question per part.

• Intake: what are all the ways work can arrive, and does every one of them land here?
• Router: what decides where something goes, and can I change that rule without calling you?
• Workers: which steps run without a person, and which still need one?
• Gate: where does it stop and ask me, and what does my screen show at that moment?
• Log: show me the record of one run, end to end, right now.
• Panel: what do I look at on a Monday morning, and what does it tell me in one glance?

Any of those six that comes back vague is not necessarily a dealbreaker. It is a thing to get specific in writing before money moves.

What to do next

Take the six-part checklist into your next proposal conversation and ask one question per part. The two that come back thinnest are where your risk is.

The gate is the part worth understanding first — where your engine stops and asks you covers how to place it. If you have not mapped your process yet, start by counting the stops.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Does every process need all six parts?

Every process that runs on its own does, though some parts get small. A simple flow might have one intake, no real routing, two workers, one gate and a minimal panel — but it still needs the log, and it still needs somewhere you look to know it is alive. What varies is the size of each part, not whether it exists.

Can we build this on top of the systems we already pay for?

Usually, and that is normally the cheaper and better answer. The workers frequently are your existing systems — your accounting package, your scheduler, your email — with the engine moving work between them and holding the state. Anyone whose first proposal is to replace everything you own should have to explain why, specifically, rather than as a general principle.

Who owns the engine and everything in it?

You should, from day one, and this is worth settling in writing before any work starts rather than at handover. Credentials in your name, accounts in your company’s name, the code in a repository you control. The test is simple: if you fired the builder tomorrow, could the next person take over what exists without asking permission from anyone?

How long does something like this take?

Weeks rather than months for a single process, precisely because five of the six parts are not being invented each time. The variable is how much has to be mapped first and how many external systems have to be connected — connecting to a modern system with a documented interface is fast, and connecting to something old or closed can take longer than the rest of the build.