Disposable Software

Disposable software is the new fast fashion.

The economics of industrialization always produce the same outcome - a bifurcation between cheap mass-market goods and expensive bespoke alternatives.

Look at furniture. IKEA’s Billy bookcase costs $79 and ships flat-packed in a box you can carry to your car. A custom bookcase from a master carpenter will start from $5000 and is built on premises to fit your room exactly. Both markets can thrive because they serve fundamentally different needs at fundamentally different price points.

But the middle always dies.

Once quality drops below a threshold, price becomes the only differentiator. Why buy a $500 bookcase when it is only marginally better than the $79 Billy. Especially when the warehouse doesn’t even serve köttbullar.

Software is following the same trajectory. For under $100 in tokens, Claude can generate a functioning CRUD application that a few years ago would have cost $5-50K. Yes, it’s generic. Yes, it will be a nightmare to maintain. But for many businesses, this is actually good enough. The $30K “custom” web agency build that’s really just WordPress with a premium theme and some custom CSS is the $500 bookcase.

The value proposition is collapsing because the quality gap between disposable and bespoke isn’t wide enough to justify the cost anymore.

The implications for producers of software are clear. Unless you have millions, or more likely billions in venture funding, it’s time to move up the value chain.

The industrialisation of textiles shifted value from yarn production to garment assembly, and eventually to marketing and distribution. Brands today spend more on Instagram than they do on manufacturing. As each layer of the production vertical becomes commoditised, value is found higher up.

With software, we are seeing this process compressed into years rather than decades. Writing code is like spinning yarn. It might be fun but it is no longer valuable because it has been commoditised. Lines of code are something to buy by the million-tokens just like cloth is bought by the m2.

Yet lines of code are not useful software any more than a bolt of fabric is a shirt. Turning LLM - or human - generated code into maintainable, scalable, context-appropriate systems requires architecture, integration, and domain understanding - the tailoring of software. And just like fashion, the tailoring market is bifurcating. Generic tailoring - making AI-generated code “work” for simple use cases - is getting cheaper and more accessible. This squeezes the middle.

Bespoke tailoring however - shaping code into robust systems for complex domains - can’t be commoditised. The expertise required to manage technical complexity, integrate with legacy systems, and encode genuine business logic remains valuable precisely because it’s hard to automate.

As developers, engineers, or architects, this is where we need to focus if we want to thrive. Not generating code, but understanding business problems and shaping code to solve them.

For consumers of software, industrialisation creates a more nuanced set of imperatives.

The democratisation of tools means your competitors have the same access to disposable software that you do. That MVP you built with Claude in a weekend? Your competitor can replicate it this afternoon. First-mover advantage decreases when moving fast is free.

Competitive advantage used to come from having software at all. Then it came from having better software. Now, disposable software gives everyone access to good-enough software for tasks that aren’t business critical. The new moat is software that’s deeply integrated with your specific context - your unique workflows, your proprietary data, your particular constraints.

That requires bespoke development. Not because bespoke is inherently better, but because it’s harder to copy. The high cost of bespoke software is what paradoxically makes it so valuable.

So the decision framework is straightforward: use disposable software for non-critical systems where differentiation doesn’t matter and invest in bespoke software where competitive advantage lives.

The hard part isn’t the framework - it’s being honest about which category each system falls into.

But there’s a trap with disposable software. If that prototype becomes your product, and that product becomes business-critical, you’re now carrying technical debt you can’t service. You can’t scale it, can’t modify it, can’t maintain it without exponentially increasing costs.

Most software starts disposable and if we are lucky it becomes successful. Planning for this transition is the difference between technical debt and technical leverage.