# Software Is Fast Fashion. > Source: > Published: 2026-09-03 16:36:47+00:00 About a year ago, I wrote a piece called Software Becomes Disposable, arguing that AI was fundamentally altering the half-life of our codebases. When refactoring and generating code become virtually free, the historic obsession with building permanent monuments starts to crumble. A year later, that reality has accelerated faster than I anticipated. But now, I have a better analogy for what we’re living through: **Software has become fast fashion.** Think about how Zara or Shein works: a designer spots an aesthetic on the Paris runway, and within 72 hours, 50,000 polyester versions are manufactured, shipped, and trending on TikTok. Three weeks later, they’re in a landfill. Consumer software is now playing by the exact same rules. An indie hacker launches an interesting utility on a Friday afternoon. By Monday morning, there are 100 vibe-coded copies on Product Hunt, GitHub, and Twitter. The barrier to entry just vanished. When anyone can churn out an app over the weekend, the app itself is no longer the asset. It’s just seasonal inventory. So in an industry addicted to rapid, disposable churn, a critical question emerges: *How do you build software that actually has longevity? How do you create something that withstands the movement of time when the code beneath it is destined to be replaced?* …Or, before we even answer that, we have to ask an even more uncomfortable question: Should we even be building for longevity? It’s an uncomfortable question for any software engineer who spent their career striving for pristine design patterns, zero technical debt, and systems built like Roman aqueducts. For decades, longevity was our default virtue. We spent weeks agonizing over database schemas, layering abstractions, and writing defensive code because changing things later was expensive. Modifying production code was like doing open-heart surgery on a running marathon runner. Naturally, you built things to survive untouched for as long as humanly possible. Now, flip the equation. If generating a full-stack CRUD application or rewriting an entire frontend from scratch takes an afternoon with AI, why spend three months architecting it to last a decade? If a consumer micro-app is essentially a seasonal garment, something users wear for three weeks because it matches a current trend, building it like an indestructible monument is just an active waste of human capital. So, the honest answer is: **No. We shouldn’t build everything for longevity anymore.** In fact, forcing longevity onto things that are inherently ephemeral is why so many teams move at a glacial pace while indie hackers eat their lunch. The trick is no longer asking “How do I make this system last forever?” The real architectural question of the AI era is: “Which parts of this system should be built to throw away, and which parts must stand the test of time?” To survive the fast-fashion cycle, I would mentally bifurcate the architecture into two radically different worlds: **What Belongs in the Disposable Bin? (The Seasonal Collection)** These are the elements I would write with the explicit expectation that they will be refactored, ripped out, or entirely replaced within 6 to 18 months: **The Golden Rule of Disposable Code: **If replacing it takes less time than documenting it, don’t over-architect it. While the garments change, the loom and the thread must remain rock solid. The 100 copycats churning out clones in 72 hours can replicate your interface, but they cannot easily replicate what sits in your foundation: When execution friction drops to zero, the premium shifts entirely to original thinking and taste. Being first to market with a genuinely novel solution matters more than ever. You have a short head start before the clone army arrives. In that narrow window, you aren’t just shipping software…. you’re defining the category. Winning the initial market isn’t a permanent victory — it’s just earning a seat in the race. Because code is disposable, the copycats will keep churning. The moment you treat your v1 as a sacred monument, a competitor will rewrite it faster and better. The illusion of software permanence is over. The winners of this era won’t be the ones trying to preserve code that was destined to expire. They will be the builders who recognize that code is just cheap fabric on a seasonal rack. Have the courage to ship the bold idea first, the wisdom to let your code be completely disposable, and the velocity to keep evolving long after the copycats run out of things to clone.