Why I Am Reinventing the Wheel

‘Why are you reinventing the wheel?’

A colleague put this question to me this week, and it was a fair one to ask. I was building a custom solution for a customer rather than configuring an off-the-shelf, ready-made generic solution. By the rules we both worked under for most of our careers, the question was rhetorical. The answer was supposed to be: you should not be. Buy the platform. Configure it. Move on.

I gave a different answer. Because the game has not changed. I am still trying to deliver the greatest possible value to the client. What has changed are the constraints, and one thing changed them: AI. Coding agents have collapsed the cost of building, and with that constraint gone, I now have a choice of route. The wheel I am building costs less than the one in your catalogue. And mine fits the axle.

The old arithmetic

For 30 years, the build-versus-buy decision ran on a simple inequality. Building custom software was expensive: architects, developers, testers, months of effort, compounding maintenance. Off-the-shelf was cheaper per unit because the vendor amortised development cost across thousands of customers. You paid a subscription. You accepted the compromise. The suit came off the rack and the tailor pinned the hem.

The entire SaaS industry was built on this arithmetic. Salesforce, ServiceNow, Workday, SAP SuccessFactors: each one a warehouse of cheap suits. They did not fit perfectly, but they were good enough, and the alternative was ruinously expensive.

Coase would have recognised the logic. Firms exist because internal coordination is cheaper than market transaction costs.¹ SaaS platforms exist because shared development is cheaper than bespoke development. Same principle, applied to software.

That inequality has flipped.

The constraints changed

Three constraints shifted, roughly simultaneously, between late 2024 and mid-2026, and they changed which route delivers the most value. All three are downstream of the same cause: AI. Each one is a consequence of coding agents becoming good enough to build production software.

Code generation became reliable enough to trust. Not perfect. Not unsupervised. But reliable enough that a developer working with an AI coding agent can produce production-grade code from a specification in hours rather than weeks. The raw speed gains are real but easy to overstate: GitHub’s controlled study clocked Copilot users 55.8 per cent faster on a single narrow task, while an independent trial found experienced developers 19 per cent slower on mature codebases.² The firmer signal is not speed but trust. Y Combinator’s Winter 2025 batch revealed that a quarter of startups had codebases that were 95 per cent or more AI-generated, and these were technical founders who could have built everything by hand but chose not to.

Spec-driven development matured. The failure mode of early AI coding was drift: the model produced plausible code that wandered from the spec, hallucinated APIs, and decayed as the project scaled. The answer was not to abandon AI coding but to constrain it. Spec-driven development treats the specification as the primary artefact and the code as its build output. Microsoft’s Spec Kit, AWS Kiro, Claude Code, and Cursor all shipped their own flavours by mid-2026. Peer-reviewed research presented at ICSE 2026 shows that incorporating architectural documentation substantially improves functional correctness, conformance, and modularity in LLM-generated code.

The harness closed the loop. This is the piece the old picture leaves out. On hearing ‘reinventing the wheel’, it is natural to picture the old model: 50 developers in an offshore delivery centre, months of sprints, compounding integration debt. That is not what reinventing the wheel means any more. The human work moves to the boundaries of the run, not the middle of it. Before the agents start, the standards, the specification and the gates are set. During the run, proxies take over: guides constrain what the agents believe, sensors correct them in flight, and gates decide whether the output is acceptable against the customer’s standards. Agents work in the background overnight, generating code from the specification; in the morning I return to judge what the proxies could not, reviewing the evidence rather than the output. The harness is the governance layer, and its operating principle is that generated code is not progress until it is tested, evidenced and traceable.³ That is what turns AI-generated code from a prototype into a production system the customer’s own team can maintain.

Why buy a ready meal when you have a chef at home?

The mental model behind the question was the supermarket freezer aisle. Need dinner? Buy the ready meal. Microwave it. Accept that it tastes like every other ready meal. It will never be great, but it will be adequate, and it will be ready in four minutes. You pay for that convenience, and not just at the till: you eat what the factory decided, in the portion it chose, with the ingredients it selected. The price of not cooking is that the meal is never quite yours.

That model worked when hiring a chef cost 10 times as much and took 10 times as long. But something has changed in the kitchen. The chef now has tools that prep, slice, and assemble at machine speed. The skill is still there for the decisions that matter: which ingredients, which technique, which balance of flavour for this particular diner. But the bulk of the labour (the chopping, the mise en place, the routine assembly) happens at a speed and cost that the ready-meal factory cannot match.

So the question inverts. When I have a chef, and that chef has the latest technology, why would I buy the ready meal? The convenience I was paying a premium for has evaporated. The chef now cooks a fitted meal in the time it took to microwave the frozen one, and I get to keep the recipe.

The ready meal still tastes generic. The chef’s dish now costs less than buying the ready meal and doctoring it with fresh herbs to make it tolerable. And the chef knows your palate. Next week’s meal will be better still, because the chef already knows what you like.

Or, if you prefer the tailor’s version: the warehouse suit still does not fit. The bespoke suit now costs less than altering the warehouse suit to make it fit. And the bespoke suit is yours. You own the pattern. You can have another cut from the same cloth next month, in a day, because the tailor already has your measurements.

That is what has happened to software. The warehouse of cheap suits, the SaaS platform with its per-seat pricing and its one-size-fits-most workflows, is being undercut by bespoke solutions that are faster to build, cheaper to maintain, and precisely fitted to the customer’s processes.

The SaaSpocalypse

The market noticed. In early 2026, software stocks shed 285billionasinvestorsgraspedtheimplicationsofAIagentsthatcouldreplaceentireSaaSworkflows.Thebroadercorrectionhassincewipedroughly2 trillion from SaaS market capitalisation. McKinsey predicts a consolidation wave cutting SaaS costs by 20 to 35 per cent by 2027, with 70 per cent of firms planning active vendor consolidation in 2026.

The trigger was not a single product announcement. It was a realisation: people who have never written a line of code can now build the software that replaces their SaaS subscription. The per-seat pricing model, charging by the number of humans who touch the software, makes no sense when humans are being replaced by agents, and the software itself can be generated from a description of what it needs to do.

Forbes called it ‘The End of One-Size-Fits-All Software’. Gartner predicts that by 2030, 35 per cent of point-product SaaS tools will be replaced by AI agents or absorbed into larger agent ecosystems. The average enterprise now runs 106 SaaS applications, down from a peak of 130 in 2022, and the number is falling.

The cost gap has closed

The numbers bear this out. A detailed analysis from Digital Applied, modelling 25 seats over 36 months, found custom build (88,600), branded SaaS (84,400), and a hybrid approach ($79,600) within striking distance of each other. The gap is so narrow that the strategic advantages (ownership, data portability, no vendor lock-in, perfect process fit) justify the marginal cost difference on their own.⁴

The hidden costs of renting are mounting. In 2025, there were 2,698 SaaS M&A deals, up 28 per cent, driving consolidation that forces customers through painful migrations. Single-year SaaS spend rose 8 per cent from consumption charges layered on subscriptions. Switching costs run at an estimated 16 times higher for organisations without portability planning. The average enterprise carries roughly $21 million annually in unused SaaS licences.⁴

When you rent, the supplier controls three levers you cannot touch. Availability: a frontier model was disabled by US export controls in June 2026, then reinstated weeks later. Price: included features shift to metered consumption. API surface: the platform you built on changes underneath you.⁴

Where the value lives

The old model puts the value in the code. It is not there. The code is the cheapest part of the engagement. AI generates it. The harness validates it. The deployment pipeline ships it. Code is a commodity.

Coding speed was never the point. The point is throughput of intent into production: how fast a requirement becomes a verified output that creates value. Once generation is cheap, the constraint moves to validation (proving the output is correct, safe and ready to ship), not to producing more of it. Generated code is not progress until it is verified; more of it, unverified, is just inventory that rots as the requirements move on. That is why the harness matters more than the model.

And it is why someone must still own the outcome, own what gets built next, and own the proof it is safe: context, value and quality. On a large engagement, those are three people with named accountability. As a one-person shop, they are three hats I wear, and refuse to let blur, because the moment the builder in me overrules the quality engineer in me, the evidence stops meaning anything.

The value is in the specification.

The value is in understanding the customer’s business process well enough to write a specification that captures what the software must do, not what some vendor assumed it should do. The value is in knowing the customer’s architectural constraints: which cloud provider, which identity system, which message bus, which security framework. The value is in encoding those constraints into a harness that makes every subsequent build faster and more reliable.

This is the insight the build-versus-buy debate misses. The question is not ‘should we build or buy?’ The question is ‘do we understand our own processes well enough to specify them?’ If yes, building is now cheaper, faster, and better fitted. If no, buying a SaaS platform is buying a substitute for self-knowledge, paying someone else to tell you how your processes should work.

That understanding does not come from a requirements document read at a distance. It comes from being embedded in the customer’s real environment (their workflows, their users, their existing systems, their production constraints), close enough to see where a prototype would break on contact with reality. Forward-deployed, in other words. Most AI pilots fail in exactly that gap, between a demo that works in isolation and a system that survives integration, permissions, data quality, governance and adoption. Closing that gap is the work.

The old consulting model was: understand the client, then recommend a product. The new model is: understand the client, then generate the product. The understanding is the product. The code is its expression.

The gravel track

I call my harness the gravel track, borrowing a metaphor from field delivery: the least infrastructure needed to move a real vehicle over real ground.³ It is deliberately minimal, the rough first road you lay down before the reusable, paved version emerges. It keeps the agent moving fast without letting it wander off course.

It is the deterministic layer around the model. The model reasons and proposes; the harness tells it what is true, what it may touch, and what evidence is required before work counts as done. A good gravel track has four parts.

Guides. What is true for this customer: their reference architecture, their approved technology list, their security policies, their integration patterns, their naming conventions. If they run event-driven microservices on Azure, every generated service follows that pattern; if they run a monolith on-premises, the harness respects that too. The agent works from a single authoritative source and has no excuse to invent.

Sensors. Immediate feedback on every change: format, compile, the nearest test, the linter, the security scan. The agent sees its own mistake and corrects it in seconds, before I am involved.

Gates. The deterministic checks that must pass before code counts as done: contract tests, the full suite, architectural fitness rules, quality and security scanners. No surprise dependencies, no unsanctioned frameworks, nothing that violates the customer’s standards reaches production.

Traceability. A record of what happened: the prompts, the commands run, the files changed, the tests executed, the approvals given. This is what turns ‘the agent produced something that seems to work’ into ‘here is exactly what was built, and the proof it is correct.’

The gravel track proves one route. Once it works, it hardens into a paved path: a standardised, reusable pattern that the next engagement starts from rather than building afresh. That progression is the moat. Not because the code inside it is secret; it is generated from specifications the customer owns. The moat is the encoded knowledge of the customer’s environment, and it compounds. Every solution that runs over the paved path is cheaper and more precisely fitted than the last.

When the warehouse still wins

I am not suggesting that every SaaS subscription should be cancelled tomorrow. Some categories of software remain better bought than built.

Commodity functions. Payroll, email, basic accounting, identity management. These are undifferentiated, compliance-heavy, and benefit from economies of scale. Building a custom payroll system is reinventing a wheel that genuinely does not need reinventing.

Compliance-certified platforms. SOC 2, HIPAA, PCI DSS certification is expensive and ongoing. If the platform’s primary value is its compliance posture, buying transfers the audit burden to the vendor.⁴

Hyperscale infrastructure. Cloud compute, storage, networking, databases. These require capital investment and operational expertise that most organisations should not replicate.

Large community knowledge bases. One genuine advantage of a widely adopted platform is the collective knowledge of thousands of other users. When you hit a problem with Salesforce or ServiceNow, someone on Stack Overflow or the vendor’s community forum has hit it before you. That shared knowledge base is real and valuable. But the advantage scales with adoption. A niche SaaS product with a few hundred customers and a quiet Slack channel offers no meaningful community advantage over a custom build. The knowledge-base argument only holds for the dominant platforms, not for the long tail of enterprise software.

Speed-critical launches. If you need a working solution by next Friday and have no specification, buying is faster. But that is a confession of unpreparedness, not a strategic advantage.

The rule of thumb: own the workflow, rent the commodity.⁴ If the software differentiates your business, if it encodes your processes, your pricing logic, or your customer interactions, build it. If it is a utility, subscribe.

A question from 2019

‘Why are you reinventing the wheel?’ is a question from 2019. It assumes building is expensive and buying is cheap. It assumes the only way to get a fitted suit is to pay Savile Row prices. It assumes the value is in the finished garment rather than the measurements. It assumes that reinventing the wheel still means 50 developers and six months of sprints.

None of those assumptions was wrong in 2019. Every one of them is wrong now.

The game has not changed. I am still trying to deliver the greatest value to the client. But the constraints have changed, and with them, the route. Building custom software from a specification, validated through an architectural harness, deployed on the customer’s own infrastructure, with agents working overnight rather than a team working for months, now costs less than buying a SaaS platform, configuring it to almost fit, maintaining the configuration through version upgrades, paying per-seat fees for agents that do not sit in seats, and carrying the switching costs when the vendor is acquired or reprices.

I am reinventing the wheel because the wheel I build fits the axle. The one in the catalogue does not. And mine is cheaper.

The warehouse of cheap suits is closing. The bespoke tailor has a new machine. And the independent professional who once needed a large firm’s infrastructure is discovering that they can generate their own wheels, cut their own cloth, and build their own software, for less than that infrastructure ever cost.

The question is no longer ‘why are you reinventing the wheel?’

The question is ‘why are you still buying wheels that do not fit?’

Sources

1. Coase, R. H. (1937). ‘The Nature of the Firm.’ Economica, 4(16), 386–405.
2. GitHub (2022) controlled study of 95 developers, published by Microsoft Research (2023): Copilot users completed a single scoped task, writing an HTTP server in JavaScript, 55.8 per cent faster (1h11 vs 2h41; 95% CI 21% to 89%). Note: METR’s independent 2025 trial of 16 experienced developers found AI tools made them 19 per cent slower on mature codebases, suggesting gains are strongest on narrow, greenfield tasks. The 55.8 per cent figure is a speed measurement on one benchmark task, not a measure of reliability or production-readiness.
3. Vaughan, D. (2026). Gravel Track to Paved Path: Shipping Cloud-Native Java to Production with AI Coding Agents. The gravel track is defined there as the minimum viable harness (guides, sensors, gates and traceability) that makes generated code trustworthy, and refined into a reusable paved path once the first route proves itself.
4. Digital Applied (2026). ‘Build vs Buy: The 2026 Case for Custom AI Tools.’ 25-seat, 36-month model: custom 88,600,SaaS84,400, hybrid 79,600.Document hidden costs of renting:21 million per year in unused licences, 16 times higher switching costs, 2,698 M&A deals, 8 per cent consumption charge increases