Code or platform? The question after the POC.

The demo went well. It always does. Someone on your team wired up a model, pointed it at a real problem, and showed a room full of people something that genuinely worked. Nobody in that room asked who would own it in eighteen months.

That question arrives later, usually in a budget meeting, and it sounds like this: do we build this properly in code, or do we put it on an automation platform? It gets framed as a technology choice. It is not. It is a decision about who can open the thing when it breaks, what happens when it breaks at 3 a.m., and whether anyone can prove it was worth building at all.

The industry has a lot of numbers about what happens next, and most of them are quoted badly. Here is the one that survives scrutiny.

For every 33 AI proofs of concept a company launched, only four graduated to production.

— IDC with Lenovo, via CIO · March 2025

The share of companies abandoning most of their AI initiatives rose from 17% to 42% in a single year, with the average organization scrapping 46% of proofs of concept before production.

— S&P Global Market Intelligence · Voice of the Enterprise, October 2025

Note what those measure. The first counts pilots that never ship. The second counts programs that get abandoned. What neither one says is that the models failed. Read the root-cause work and the picture is consistent: the technology mostly worked, and the organization around it did not.

More than 80% of AI projects fail, roughly twice the failure rate of IT projects that do not involve AI.

— RAND Corporation · Root Causes of Failure for AI Projects, 2024

So the build-versus-platform question is not really about tooling. It is about which of those two failure modes you are walking into.

Two columns, one decision

The table hides the actual decision, which is why the rest of this piece exists. Both columns get you a working thing by Friday. Only one of them is still working next year, and which one depends entirely on your answers below.

Which way does yours lean?

An interactive compass on the live page turns four leanings into a needle position. The same four questions, with each option’s lean, follow below.

1. What is at stake when it breaks?
   • Code lean: A hobby project — no customer data, no money
   • Platform lean: Regulated or money — records, payments, trust
2. Who owns it in eighteen months?
   • Code lean: Builder keeps it — same person, forever
   • Platform lean: Someone else — a handover is coming
3. How often, and how many?
   • Code lean: One, occasional — your first automation
   • Platform lean: A whole fleet — dozens, high frequency
4. Who is deciding?
   • Code lean: Fixed rules — no judgment needed
   • Platform lean: A model, in a loop — judgment inside repetition

Four questions, in order

Most versions of this decision get presented as a checklist. Checklists imply the items carry equal weight. They do not. These are ordered so that the first question that gives you a hard answer ends the discussion, and you can stop reading.

What does it cost when this goes wrong?

Start here, because this one overrides everything below it.

A hobby project on a spare server, touching no customer data and no money: your risk tolerance is close to unlimited. Build it however you build things fastest. Nothing else in this article applies to you, and you should stop reading and go build it.

A process at a regulated firm, touching customer records or moving money: the questions multiply immediately. Can the thing send, or only read? Is a mistake reversible? Will a failure be loud, or silent for six weeks? Who can see the credentials? And the one that decides most of these projects: will security approve something they cannot inspect?

AI raises the stakes in a specific way. The less visible the decision path, the higher the risk, whatever you built it on. When consequences are real, you need the AI’s decisions logged and bounded, and legible to someone who was not in the room when it was built. That is achievable in code. It is just work that most teams do not budget for, and the work is the same work regardless of which column you picked.

• The loud failure — A process that stops and shouts gets fixed by Tuesday. Not the one to fear. (fixed by Tuesday)
• The quiet failure — A renamed field, a timed-out API, a model returning plausible nonsense, and nothing anywhere says so. (runs for five weeks)

Which brings up the 3 a.m. question, since things do break at 3 a.m. The failure you should fear is not the loud one. A process that stops and shouts gets fixed by Tuesday. The expensive failure is the quiet one: a renamed field, a timed-out API, a model that starts returning plausible nonsense, and nothing anywhere says so. That one runs for five weeks, and by the time somebody notices, a quarter of your data is wrong. Retries, alerting, and a log somebody actually reads are not features you add after launch. They are the difference between an automation and a liability, and they are the first thing to get cut when the timeline slips.

Who owns this in eighteen months?

This question changes the answer more often than any other, and it is the one executives are best placed to answer, because it is not a technical question at all.

If the builder and the maintainer are the same person forever, pick whatever is fastest. If they are not, you have a handover problem, and handover problems are where automation goes to die. There are three distinct roles here and they need different things:

1. Who builds it — A developer has every option available. A marketing or ops person has exactly one path to being a builder at all, and it runs through something they can see.
2. Who maintains it — A year out, an API changes or a prompt needs adjusting. If that person did not build it, they need to open it and understand it in an afternoon. A visual workflow can be read by someone who could never have written its code equivalent. That is not a small property.
3. Who changes it — Higher bar than understanding. Can a non-technical teammate swap a credential or edit a schedule without filing a ticket? If every small change routes through one technical person, that person is now the bottleneck for the whole function, and in practice they end up resenting the thing they built.

The handover test is blunt: if the person who built this left next month, does it survive? Something a colleague can open and follow survives. Code that only its author understood keeps running until the day it breaks, and then nobody wants to touch it.

There is a live wrinkle here worth naming. Generated code is fast to produce and often nobody, including the person who prompted it, has a full mental model of it. The maintenance question does not go away because the code was cheap to write. It gets sharper, because the usual defense (the author remembers why) no longer holds.

How often does it run, and how many of these do you have?

That is really two questions, and they need separate answers.

Frequency drives cost. The arithmetic is not complicated. A deterministic process running 500 times a day costs approximately nothing per run. The same job with a model reasoning through it 500 times a day costs 500 model calls a day, forever, and re-decides something you already decided. If you can write down rules that cover every case, write down the rules. Paying a model to re-derive them is not just waste, it introduces the chance of a different answer on run 79.

Fleet size is the question nobody asks until it is too late. Your first automation can live anywhere. Your fortieth cannot. Once dozens run in parallel you need one place that shows all of them, what ran, what failed, and a way to rerun the failure after you fix it. That requirement arrives suddenly, and retrofitting it across forty bespoke scripts is a project in itself. This is the single most common reason organizations standardize on an orchestration layer, and it has nothing to do with any individual automation being better there.

Now the part the platform vendors would rather you worked out later. Most orchestration tools price per execution, per task, or per seat, and the tier that includes the governance you actually need (audit logs, role-based access, a private deployment) is rarely the tier you start on. Model a process running 500 times a day against your candidate’s pricing page before you commit, then model it at 5,000, because the second number is the one that ends the relationship. Self-hosting changes that arithmetic and introduces a different cost, which is that you now operate the platform too.

There is a harder ceiling than price. Platforms are good until your logic stops fitting in their boxes, and the failure mode is not a wall, it is a slow accumulation of workarounds: a code node here, a webhook into a side service there, until you are maintaining a distributed system that happens to be drawn in someone else’s product. If your process has real algorithmic complexity, that day comes early. And your escape route is worth pricing at the start: exporting a workflow is easy, but exporting the runtime it depended on is not, and “no lock-in” is a claim to test rather than accept.

No product names here, on purpose. Any shortlist written today will have reshuffled by the time you read it, and the questions above outlive all of them. Whichever tools make your list, run the same test: build one real process on it, then hand it to someone who did not build it and watch what happens.

Who is deciding: the rules, the model, or a person?

Last, because it is the most interesting and the least decisive. This is the question everyone opens with. It is also why so many of these projects end up in the wrong place.

• The rules — No judgment. Move every invoice from mail to storage, same way, every day. Make it deterministic and stop thinking about it.
• A person — Judgment end to end. Research, drafting, cleaning up a messy one-off dataset. You are steering, each step depends on your read of the last one. That is an agent session with you in the loop, and wrapping process around it adds nothing but overhead.
• The model — A decision inside repetition. Five hundred support tickets a day arrive the same way and route the same way, and somebody has to read each one and decide what it is about. That somebody can be a model, sitting at one visible step in the middle of a structure that is otherwise deterministic.

And the sub-question people skip: when does the decision get made? There is a large difference between a model that drafts a reply for a human to approve and a model that sends it. If a human approves, that checkpoint is part of your process and it needs to be visible in whatever you build.

Where it usually lands

Four questions, and most people find one of them answers the whole thing before they reach the others.

The trade is velocity against reversibility. When the downside is small, velocity wins and that points to code. As the downside grows, being able to see and undo what happened outranks speed, and that points to a platform. Most organizations sit in the middle, and that is why the answer is so often both. That is not a dodge. The split usually falls in a specific place: the recurring skeleton is a workflow, and the one step that needs judgment is a model call inside it, where you can watch it.

Nobody knows how much faster they are

In February 2026 a research nonprofit published a post explaining that its own most-cited finding no longer described reality, and that the replacement number it was offering should not be trusted much either. That is the most useful thing in this article, and almost nobody quoting the original has noticed it happened.

Start with the finding itself:

Retired by its authors, Feb 2026

Experienced developers took 19% longer to complete real tasks when allowed to use AI tools, while estimating afterward that AI had made them 20% faster.

— METR randomized controlled trial · July 2025 · 16 developers, 246 tasks

That got quoted everywhere as proof that AI coding tools do not work. It is still being quoted that way this month. But METR ran it again with later tools and published what they found.

For the subset of the original developers who participated in the later study, we now estimate a speedup of 18%. Among newly recruited developers the estimated speedup is 4%.

— METR · February 2026, on late-2025 tools

They went further and labeled the original result out of date on its own page, in a red box, above the abstract.

One study, two numbers that should have matched:

• Felt faster: +20%
• Was slower: −19%
• Gap, in their own favor: 39 pt

Two things follow. First, anyone citing the 19% figure today as current is citing something the authors have retired as a description of present conditions. That is a cheap and effective test of whether a vendor reads past headlines. Second, and more usefully: the developers in that first study were wrong about their own productivity by 39 percentage points, in the direction of flattering themselves. They were experienced people working in code they knew well.

Your team is not exempt from that. Neither are we. Which is why the answer to “is this faster?” is never a show of hands. It is a measurement taken before you start, and the same measurement taken again after, by the same method, with both dates written down.

Write the kill criterion first

Every decision above assumes this thing should exist. Sometimes it should not, and the moment to establish that is now, while everyone is still optimistic, because that is the only moment a kill criterion can be written honestly.

Before you pick a column, write down the result that means you stop. Not “if it does not work.” A number, with a date attached. The shape is always the same three:

1. A quality floor — Routing accuracy below X at week six.
2. A cost ceiling — More than Y per run once volume is real.
3. A handover test — Nobody outside the build team has opened it by week four.

Your numbers will not be ours. What matters is that they exist, in writing, before anyone is invested in the answer.

That third one gets left out most often and predicts the most. If the only person who can open it is the person who built it, you have not learned that you need more engineering time. You have learned the answer to question two, and no amount of further engineering fixes it.

This is the Bearing phase of AZIMUTH, the method described on the Method page. It is the phase clients push back on hardest, right up until the first time it saves them a quarter.

What the research above establishes is narrower than what people usually claim from it. IDC attributes the 33-to-4 ratio to organizational readiness: data, processes, infrastructure. RAND points at leadership and communication. No one in that research says “nobody was allowed to stop.” That part is our read, from our own engagements, and we will mark it as such: the projects we have watched consume the most budget were rarely the ones that failed fast. They were the ones with no agreed definition of failure, which drifted until someone senior lost patience and cancelled the entire program rather than the single bad bet inside it. A defensible stop is cheaper than a slow abandonment, and the board that watched you stop one project cleanly approves the next one faster.

So answer the tooling question carefully. It matters. Just answer the other one first, in writing, while everybody still thinks the project is going to work: what would have to happen for us to stop this? If nobody wants to write that sentence down, the tool you pick is not going to save you.

Last reviewed July 2026. These pages are re-read quarterly; corrections are logged, not silent. If a figure here has gone stale, that is a bug, and hello@bearingbridge.com reaches us.