The Build vs Buy Decision in 2026: A Correctness Matrix

“Can we build this?” used to be the hard question. In 2026, the answer is almost always yes. The harder question is whether you should.

Wiley Jones, CEO and co-founder of Doss — the AI-native operations platform serving mid-market physical operations companies like Verve Coffee and Eight Sleep — has a framework his team uses every time the build-vs-buy question comes up. It’s not complicated, but it catches the mistake most teams make: conflating technical feasibility with strategic value.

The correctness variable

The first axis in Jones’s matrix is the cost of being wrong. Not the probability of errors — the consequences.

“Anything where correctness matters a lot, you should probably avoid building yourself,” he says. “We’re not going to go build and vibe-code a system for us to run our payroll. That would be really dumb. Spending, expense, managing credit cards for our company — we use Ramp. Ramp is great. It’s an amazing product. There is absolutely no reason that anyone should try to vibe-code their own spending expense.”

Payroll errors have legal consequences. Expense management errors create audit liability. These are domains where being 95% correct isn’t good enough, and where a proven product has already absorbed the edge cases you haven’t thought of.

On the other end: “The project management tool that we’re using to coordinate some of the management across our portfolio of work — we had a bunch of weird requirements and it didn’t fit nicely into Asana or Linear or Notion or Smartsheet. So we just made our own thing. It took us a couple of days.”

The key distinction: “If a product is slightly wrong and the data is slightly not correct or the experience is not slightly perfect — it’s okay. You can fix a bug in that. It’s not really an issue.”

The effort variable most people forget

The second axis is one that trips up technically capable teams: is building even worth the time, regardless of difficulty?

Jones uses calendar scheduling as his example. “Could you vibe-code a Calendly? You could probably vibe-code something pretty similar to it, but is it worth doing now? Not really. It’s not worth doing.”

This is the question that separates engineering judgment from engineering capability. The ability to build something quickly doesn’t mean the time is well spent. Calendly is annoying but functional. It has integrations you’d have to rebuild. The marginal improvement from a custom version doesn’t justify the ongoing maintenance, even if the initial build is cheap.

The matrix in practice

Put the two axes together and you get four quadrants:

• High error cost, unique requirements: Buy a proven product. This is payroll, expense management, compliance tooling. The stakes are too high and the domain expertise too deep.
• Low error cost, unique requirements: Build it. This is Jones’s project management example — the requirements are genuinely unusual, mistakes are cheap to fix, and a weekend of building gets you exactly what you need.
• Low error cost, standard requirements: Don’t bother. This is the Calendly quadrant. You could build it, but why? The existing product works. Spend the time on something that actually differentiates your company.
• High error cost, standard requirements: Also buy, but for a different reason. The proven product has already handled the edge cases, compliance requirements, and integration challenges. You’re not just buying features — you’re buying institutional knowledge about failure modes.

The Waymo test

Jones offers an extreme version of the correctness question as a gut check: “Is it a Waymo? Cause if it’s a Waymo, and the cost of an error is you hit somebody and they die — don’t build that yourself.”

The Waymo test isn’t really about autonomous vehicles. It’s about recognizing that some domains have consequences that compound beyond the immediate error. Financial accuracy, healthcare compliance, physical safety — these are areas where “move fast and fix bugs” creates liability that a startup can’t absorb.

The honest answer for most teams is that very few things they build are anywhere near Waymo territory. But the exercise of asking forces you to name the actual consequences instead of assuming everything is equally risky.

FAQ

How should startups decide what to build vs buy in 2026?

Use a two-axis framework: error cost and effort value. If errors are catastrophic (payroll, compliance), buy a proven product. If errors are cheap and your requirements are unusual, build it — AI coding tools make the initial build fast. If the existing tool works well enough, don’t bother building regardless of how easy it would be.

What is Doss and why did it raise $55 million?

Doss built an AI-native Adaptive Resource Platform for mid-market physical operations companies ($20M-$250M revenue). It replaces fragmented ERP stacks with a composable system that implements in 3-4 months. The $55 million Series B was co-led by Madrona and Premji Invest, positioning Doss as an AI inventory layer that integrates with existing enterprise systems.

What does Doss’s implementation process look like?

Doss can build a tailored demo in about two hours but takes three to four months for full implementation. The bottleneck isn’t technical configuration — it’s human coordination: getting organizations to decide how they want to operate, aligning stakeholders, and mapping existing business processes. Value engineers work alongside the customer to build a technology roadmap.

When should you vibe-code an internal tool instead of buying SaaS?

When the cost of errors is low, requirements don’t fit existing products, and the tool is genuinely unique to your workflow. Wiley Jones’s team built a custom project management tool in days because Asana, Linear, and Notion didn’t fit their needs. The test: if the product is “slightly wrong and the data is slightly not correct — it’s okay. You can fix a bug.”

Is it worth building your own Calendly or similar commodity tools?

Usually no. Even though AI coding tools make it technically easy to replicate commodity SaaS, the ongoing maintenance, integrations, and edge cases eat time. Jones says some tools are “annoying enough” but functional — and rebuilding them “wastes time even when technically easy.” Spend building energy on things that differentiate your company.

What is the Waymo test for build vs buy decisions?

An extreme version of the error-cost question. If the consequences of your system being wrong are catastrophic — comparable to an autonomous vehicle hitting someone — don’t build it yourself. Buy a proven product that has already absorbed the domain expertise, edge cases, and failure modes. Most internal tools are nowhere near this threshold.

How is AI changing the build vs buy equation?

AI coding tools collapsed the cost of building, making the “can we build it?” question almost always yes. The harder question is now “should we?” — which depends on error consequences and whether building is worth the ongoing maintenance. Jones says the competitive benchmark for SaaS pricing has shifted from engineer salaries to intelligence-per-token costs.

Should product companies rewrite their software for AI?

Wiley Jones says “100%.” Product-based companies with no genuine technology underneath will be “completely destroyed.” The only durable paths are deep technology (architecturally complex, hard to replicate) or strong brand (emotional connection customers pay for). Products in neither category face existential pressure from AI-generated alternatives.