Time and Tokens: When Software Stops Being Something You Buy

Part 1 of 3 · The Time and Tokens series

For a generation, buying business software meant doing things someone else’s way; you had your way of doing things, and then you bought a tool that had its way, and the gap became your problem. You renamed your stages to match its pipeline. You abandoned real workflows because the software “didn’t support that.” You paid for 112 seats and used 23.

That was the right deal for most of that time. Building your own was insane - hire engineers, wait a year or two, spend hundreds of thousands, if you’re lucky you launch, and then you get to maintain the thing forever. Off-the-shelf software, with the cost spread over a whole market, won on price and safety almost every time. “Buy, don’t build” was close to a law of nature.

What changed was that AI collapsed the cost of building. Not to zero, but far enough that the old calculation no longer describes the world. The two remaining inputs are time and tokens. The flip is showing up in the numbers, too. In Retool’s 2026 build-vs-buy survey of its own customers (a crowd already inclined to build, so use your pink Himalayan salt accordingly), 35% had already replaced a SaaS tool with something they built themselves, and 78% expected to build more this year.

Writing software used to require a scarce, expensive, slow resource - engineering hours, purchased in bulk, arranged in advance. Now a capable person who understands the business can direct AI tools to assemble working software in a fraction of the time (a question Part 3 takes up). What’s left is describing what you want clearly, and the tokens spent turning that into a working thing.

That first half is the time, and it’s yours; hours of thinking hard about what the thing should actually do, which is not work you can hand to anyone else. The second half is the tokens, which is just money. Both are elastic in a way engineering hours never were, they scale with the problem rather than a vendor’s pricing tiers. Tokens also stretch, because you can buy more. Time doesn’t - a small problem takes less of it, and you cannot buy more time.

“A dynamic tool changes with your process, as it happens, not when some vendor decides to ship it.”

Picture the tool no vendor will ever build for you, the one that reconciles your shipping export against your accounting import, flags the three SKUs that always disagree and pings the person who knows why. Too small to be a product, too specific to be a feature request. That’s the tool that used to stay un-built. Now it’s an afternoon.

Dynamic, not throwaway

The fashionable version of this is “vibe coding,” Andrej Karpathy’s term for building with an LLM and not reading what it writes. Simon Willison, who is friendly to the practice, still fences it off - it suits throwaway projects, and his rule for anything real is that he won’t commit code he couldn’t explain. Hold onto that rule, because it is the sharpest objection to everything in this series, and Part 3 is where I have to answer it.

The narrower point for now; what matters when your company runs on a tool isn’t how the code got written. It’s what happens to that tool over the next three years. The better frame is that software stops being a monument and becomes dynamic. A monument is what you buy, decided once, then organized around. A dynamic tool changes with your process, as it happens, not when some vendor decides to ship it.

When a step appears, you add it; when one’s pointless, you cut it. The tool tracks the business instead of the business bending to the tool. The software used to be the fixed thing; the process did the flexing. Now the process can be yours, and the software flexes.

The Siebel warning

We’ve lived a version of this before. Twenty years ago companies bought Siebel and customized it, heavily, exactly to their process. Then the upgrade came and they couldn’t take it (it’s happening now with heavily customized Epic builds). The customization that made it theirs was the same thing welding them to a dying version. Their wish became their death wish.

And AI can make that worse. Customization used to have friction, and friction is a brake; now the surface grows faster than anyone’s understanding of it. With Siebel, a vendor still maintained the core. Own the whole thing and the entire surface is yours (security holes and 2 a.m. breakage included). Worst of all, when a person wrote the code, the reasons lived in their head. When a model generates it, that “why” may never have existed in a human mind at all (you can’t ask it what it was thinking, because it wasn’t). You start with a gap instead of accumulating knowledge.

Which is why documentation isn’t enough. A document records what was built; it can’t hand over the judgment to change a live system without breaking it. That judgment comes from running the thing, debugging it under load, holding the model in your head. Matt Wood makes the same case in “The Cost of the Answer”, producing the answer was never the valuable part; knowing if it’s a good one is. A document that records the decisions, and not just the result, gets closer; most don’t, which is why the knowledge ends up living in a team.

So the honest correction is that it isn’t just time and tokens. Tokens got cheap. The standing team that keeps bespoke software running did not; that’s the hidden third input, the expensive one. “Buy” existed largely to rent that team and split it across thousands of customers. Build, and you hire it back.

None of this means there’s only one answer. Examine your subscription and licensing costs. Examine your in-house ability to document, design, build, test, iterate and support a product, and budget for that team from the start; it’s the one you still pay full price for. The record on that is not encouraging. Deloitte’s Bill Briggs puts 93% of technology funding into the technology and 7% into the people expected to use it, and Puneet Badlani reads that split as the failure itself, on the grounds that capability lives in the people working with a tool rather than in the tool.

Commodity and regulated software you’ll mostly keep buying; the software that only your business needs is where building now wins. There will be times where it makes sense and times where it won’t, and that’s OK. What’s new is that build is a real option at all for that work; it never used to be. Think it through before you jump to an answer on build versus buy.

Just remember that a tool shaped exactly to you is a tool only you can keep running. The bending stops, but the tending is now your job, and it doesn’t end.

---

Next in this series: Part 2, “Value, Not Hours: Pricing Services When the Work Takes Two Weeks” (the same shift, seen from the other side of the invoice), and Part 3, “The Whole Pool: Who Actually Builds Software Now” (who that “capable person who understands the business” turns out to be) - coming soon.

Further reading: Simon Willison, “Not all AI-assisted programming is vibe coding”, on where the line actually sits; the “SaaS vs vibe-coded TCO field guide”, which costs five years of ownership rather than the build; Retool, “The 2026 Build vs. Buy Report”; Matt Wood, “The Cost of the Answer”, on why judgment, not cheap generation, is the input that compounds; Puneet Badlani, “The 93/7 Problem”, on the budget split that starves the people side of the same shift.