Build in-house vs platform: 6–12 months vs 3 weeks

The build-vs-buy decision usually comes down to a spreadsheet, and the spreadsheet usually lies. Not on purpose — it just counts the things that are easy to count and quietly omits the things that end up mattering most. So let's start with the one number the spreadsheet gets directionally right, then talk about everything it leaves out.

Six to twelve months to production for a build. Three weeks for a deployed platform. That gap alone should give a builder pause, but time-to-production is the least interesting part of the comparison — it's just the part that shows up first. Here's the full picture the deck lays out, and then the four line items your own spreadsheet almost certainly missed.

What the spreadsheet always undercounts

A build-vs-buy model typically has two columns: the cost to build (engineer-months, roughly) and the cost to buy (the license). It comes out looking close, or even favoring build, because engineering time feels like a sunk cost you're already paying for. Then you build it, and the real costs — the ones that weren't in the model — start arriving.

The eval infrastructure. The demo is not the product. Getting a model to work in a demo is a few weeks; getting it to work reliably in production, and knowing it works, is the rest of the year. That knowing requires an eval harness — a versioned set of real cases you score every change against, so you can tell whether a tweak helped or quietly broke something. Almost no build-vs-buy spreadsheet has a line for the eval harness, because almost nobody realizes they need one until their unmeasured model plateaus and they can't tell why. (It's the same eval-harness gap that stalls pilots — the plumbing nobody budgets for.)

The audit trail. In any workflow a regulator, auditor, or customer might scrutinize, "the system decided" is not an acceptable answer. You need approval, override, and a logged, attributable trail behind every decision. Built in-house, that's a whole subsystem — and it almost always gets deferred, because it's not what makes the demo impressive. The spreadsheet assumed you'd add it "later." Later has a cost, and it arrives right when an auditor asks a question you can't answer.

The burden the model prices at zero

The spreadsheet treats "engineer-months" as the cost of building. What it doesn't price is the ongoing burden of owning the thing after it ships — and that burden doesn't fall on engineering alone. It stretches product, ops, and eng simultaneously and permanently.

Product owns a roadmap that now includes an internal AI tool competing with everything else customers want. Ops owns a workflow they can't change without filing a ticket. Engineering owns a model that needs monitoring, retraining, an eval harness, and an on-call rotation for when it misbehaves in production. None of that ends at launch. It's the standing tax of having built the thing yourself, and it runs for as long as the workflow exists.

A platform inverts this. Qrambo designs, deploys, and maintains the workflow with your team — the burden of keeping it running, measured, and improving sits with the people whose whole job is keeping it running, measured, and improving. Your product, ops, and eng teams stay pointed at your actual product. The detailed cost breakdown walks through where these hidden line items land and roughly what they run.

Control and improvement: the two you can't retrofit cheaply

Two rows in that table look like features and are actually architecture, which is why they're so expensive to bolt on after the fact.

Human control — approval, override, and audit trail — has to be designed into the flow from the start, because it changes how every decision moves through the system. Build the autonomous version first and add control "later" and you're not adding a feature, you're re-architecting the decision path after it's already in production. On a platform built around human-in-the-loop, control is day one, not a later project: every case is approvable, every decision overridable, every action logged.

Control isn't all-or-nothing, either. The practical mechanism is a confidence threshold that decides which cases clear automatically and which route to a human — and a platform gives you that dial from the start, tuned to your risk appetite. Move it and watch the trade-off:

That dial is itself a piece of infrastructure the spreadsheet forgets. In a built system, "route the uncertain cases to a person and auto-clear the confident ones" is another subsystem to design, wire, and tune. On a platform it's a setting.

Product improvement is the row that decides whether the system is alive or frozen. In a built system, every change is an eng ticket — the workflow improves at the speed of your engineering backlog, which is to say slowly and grudgingly. On a platform where workflows improve from live operator feedback, the corrections your team makes in the course of their normal work feed back into the system automatically. Every override is a signal that lifts next week's accuracy, no ticket required. One system is a snapshot that decays; the other is a loop that compounds. That's the difference between owning a tool and adopting an operating model.

The 90% problem

There's a specific reason builds run 6–12 months instead of the six weeks the first estimate promised, and it's not that anyone estimated badly. It's that the demo — the part that's genuinely quick — is maybe 10% of the work, and it's the visible 10%. It's the part you show a stakeholder to get the project funded. The model reads a document, makes a call, looks impressive. Six weeks, tops.

The other 90% is everything that makes it safe to run without watching it: the edge cases the demo didn't hit, the malformed inputs, the failure modes, the monitoring that tells you when it's degrading, the eval harness that proves a change helped, the audit trail an auditor will ask for, the override paths for when it's wrong, the retraining pipeline so it doesn't decay. None of that is in the demo. All of it is in production. And it's invisible in the estimate precisely because it's invisible in the demo — you don't know to budget for the failure mode you haven't hit yet.

This is why "we already have the engineers, so building is basically free" is the most expensive sentence in the build-vs-buy conversation. The engineers can build the 10% fast. It's the 90% that consumes the 6–12 months, and it's the 90% a platform has already built, tested against many customers' edge cases, and folded into the price. You're not comparing your team's speed against a vendor's. You're comparing building the unglamorous 90% once, alone, from scratch — against buying it already built.

How to run the comparison honestly

If you're weighing build against buy, the fix isn't to throw out the spreadsheet — it's to add the rows it's missing. Put a real number on the eval harness: who builds it, who maintains it, what it costs to keep a versioned case set scored on every change. Put a number on the audit trail as a first-class subsystem, not a "later." Put a number on the standing burden across product, ops, and eng — not just to build, but to own — for as long as the workflow lives. And put a number on the eng ticket behind every future change, multiplied by how often ops will actually want to change something (the answer is: constantly).

Add those rows and the comparison stops being close. Six to twelve months of build, plus the eval infra, plus the audit subsystem, plus a permanent three-team tax, plus a workflow that only improves as fast as your backlog — against three weeks to production on a system that ships with control and a learning loop already in it. This is the branch's whole thesis: the choice was never really "build a tool or buy a tool." It's whether you want to build an operating model from scratch or adopt one that already works. The product page shows what adopting it looks like in practice; the real-cost breakdown shows what building it actually runs once the forgotten rows are filled in.