Build the moat, buy the rest

"Build or buy?" is one of the oldest questions in software, and most teams still ask it the wrong way. Two projects taught us a better version: one by showing how to do it right, the other by costing us three months.

A research team that built only its moat

A team of university researchers noticed companies haemorrhaging money on cross-border expansion: local consultants, penalty fees, months of legal review for every new market. They knew legislation followed patterns that nobody had connected across 150+ countries.

They started with £200,000 in grants. What's instructive is what they didn't do. They didn't hire a dev team, build custom infrastructure or create their own design system. They bought the boring parts and built only the moat:

• Outsourced: UI/UX design and the initial product engineering.
• Built in-house: the LLM pipeline that scrapes, translates and normalises legislation.
• Used off the shelf: everything else, mostly spreadsheets.

For the first eighteen months they were a team of five. They secured their core advantage, an AI that could map a paragraph of Japanese corporate law to its German equivalent, while vendors handled the rest.

Then the Series A came, and they grew to fifteen people with the same philosophy. The core team stayed small and focused on the legislative engine. They committed to three or four reliable technology providers for databases, hosting and auth. Vendors built supplementary features and proofs of concept.

Today they're at Series B, with 80 core employees and several product lines. Only now have they started consolidating everything into their own vertical workflow platform. Not because they couldn't afford it earlier, but because they've finally proven what needs to be custom and what doesn't. The platform serves some of the largest payment processors and professional services firms working on cross-border M&A.

A pilot we nearly lost

Our own lesson was less comfortable. Three months into an enterprise pilot, the client's data protection team asked the question we'd been dreading: "Does this comply with our corporate policy? We can't send customer data to third-party AI providers under GDPR."

We couldn't guarantee it. Our AI calls went to US-based providers.

Six months of architecture decisions went in the bin, followed by three stressful months rebuilding the AI integration from the ground up. It was a valuable lesson, and one every software team should take to heart.

The underlying problem isn't going away. Enterprises struggle to keep pace with how fast AI changes. Many lack clear AI policies; others have only vague guidelines. Their data protection frameworks were written for a world before AI took centre stage. By the time they've worked out their requirements, you may already have committed to things you'll regret.

What we wrote into our Experience Bank

The two stories look unrelated: a startup's growth strategy and a vendor's integration mistake. Both come down to knowing what's actually yours to build.

• "Build or buy" is the wrong question. Ask "what's our actual moat?" Your core value is what your team should focus on; everything else is scaffolding.
• Don't build around your org chart. Build around your unfair advantage.
• Buy when it's cheaper; build as a last resort. Earn the right to consolidate later, once you know what really needs to be custom.
• Build around the client's AI infrastructure, not yours. Don't spend energy persuading an enterprise to trust your setup; fit into the one they already have.
• Leave customers sovereign over their data. If they keep full control of their information and still get the value, you've removed the biggest reason to say no.

The research team knew their moat was the legislative engine, so they spent nothing on anything else. We learnt that our moat was never the AI provider we happened to call. It was what we built on top, and that should have been portable from day one.