Building In-House Doesn't Mean Building From Scratch

"We're building it in-house."

I hear some version of this almost every week, and I don't think it's wrong. It's usually just aimed at the wrong layer of the stack.

The instinct behind it is right. No vendor knows your workflows, your exceptions, or your edge cases the way your own team does. You want to own the system and the roadmap, and you don't want to wait on someone else's release cycle. I'd want the same thing.

What I'd push on is what "in-house" actually has to mean. It doesn't have to mean building from scratch. It means your team builds and owns the AI agents that run your high-stakes workflows, and that's a different thing from your engineers hand-building the infrastructure underneath them.

Here's what I've watched happen a few times now. A team reaches for a generic tool, patches around the gaps for a year, and concludes the only way to get it right is to build the whole thing themselves. They're usually right that the tool was never going to fit. But the problem was never that they wanted to own the workflow. It's that the only two options in front of them were a tool that didn't fit, or an engineering team building the entire stack from the ground up just to make it fit.

DHL is this at the largest possible scale. After acquiring Danzas and Exel, they spent roughly €750 million on the New Forwarding Environment, a from-scratch platform meant to unify the acquired operations. It got shelved. Not for lack of capability or capital — DHL is one of the largest logistics companies on earth. Their own complexity outpaced their engineering budget, and hiring didn't close the gap.

The same thing happens at every scale, just quieter. The scope creeps: one workflow turns into every integration you'll ever need, then compliance logic that has to survive an audit, then exceptions nobody scoped for. That isn't a one-time cost, it's a standing headcount commitment that nobody put in the original business case. And the engineers who understand the system best become a single point of failure the day they leave. More budget and more headcount help, but past a certain point the complexity grows faster than you can staff for it.

So where's the line?

If building in-house means your team builds it, does that include writing your own prompts? Orchestrating the model calls? Building your own document processing underneath them? Training your own models?

You're never really building from scratch. You're choosing which layer you start from. The only question worth arguing about is which layer gives you what you need today and keeps getting better on its own.

Reform is built to be that layer for complex operations whose product isn't software. Your team builds your own agents on it and defines the processes, the exceptions, and the rules. Our team is there to help you get the most out of it. We're the infrastructure underneath, not a vendor running your workflow for you.

A third of the companies on Reform today first tried to build in-house. They didn't give up on building it themselves. They stopped hand-building the infrastructure underneath it. Most have an agent in production within thirty days, some in twenty minutes, automating work for goods worth tens of millions of dollars.

So the build-in-house decision was never really about whether to own the system. Everyone wants that. It's about which parts are worth building by hand, and which parts are now simply building blocks.

Your edge is your operation, not the software running underneath it. Reform is where your team builds the automation and keeps the ownership.