Fast-Fashion Software: Disposable Tools, Compounding Taste

Most software an operator ships in the next decade should be disposable. The dashboard for this quarter's campaign. The microsite for next month's event. The internal tool that turns a painful Tuesday handoff into a single button, used heavily for ninety days and then deleted. The reconciliation script that solves a one-time data mess. None of these need to live forever. None of them need a roadmap, a quarterly review, or a successor team. Fast-fashion software is the natural operating mode of the IC age—and treating it as a failure of seriousness is the most expensive mistake teams will make over the next three years.

SCQA (at a glance)

Situation: Software used to be slow and expensive to build, so we treated every artifact like a long-lived asset. Complication: AI makes most software disposable cheap to ship, and lifetime-of-asset expectations no longer fit the unit cost. Question: What should operators build, and what should they refuse to build that way? Answer: Treat most tactical software as fast-fashion—short-lived, fit-for-purpose, replaceable—while keeping a small set of compounding assets (skills, knowledge, brand, identity) treated like the long-lived infrastructure they are.

We used to treat software like a building. It was priced like one.

For most of the industry's history, software was expensive enough that every artifact carried a capital-asset assumption. We staffed teams to maintain it, wrote five-year roadmaps, planned for migrations, argued about architecture three years before the second user existed. That was rational when the marginal cost of building anything was high—the asset had to amortize. It was the operating logic of the monolithic product org described in The End of the Monolithic Product Org.

That economics is over for a large class of work. When the operator can ship a working version in an afternoon—described in As Fast As You Can Think and powered by the stack in The Individual Contributor Age—the cost of a purpose-built tool is now closer to the cost of a spreadsheet, not the cost of a building. You stop trying to amortize. You ship, use, and replace.

What fast-fashion software looks like in practice

It looks like the operator's personal toolbelt, full of artifacts that are explicitly seasonal:

One-shot dashboards. Built in a session to answer a specific business question; deleted after the quarter that needed them closes. No backlog. No on-call.
Seasonal microsites. The campaign landing page, the event registration, the partner portal that exists for ninety days. Standing up a beautiful, accessible, well-instrumented version takes an afternoon when the skill library is mature.
Internal one-off tools. The reconciliation utility, the migration script, the "why did this metric move" explainer. Used once. Sometimes never run again.
Throwaway analyses. The model that scored last week's creative tests. The pull forecast for the next launch. Useful for a specific decision, not the basis of a product roadmap.
Decision-grade prototypes. Working software shipped specifically to kill the underlying idea cheaply—a piece of falsification, not a piece of inventory. The most underused mode in enterprise software, and the most aligned with the mindset case in The Battle of Mindsets.

Every one of these used to require a project. None of them does now, and that is the point. Calling them disposable is not a slur; it is a description of the right operating life expectancy.

Why disposability is a feature, not a failure

Three reasons fast-fashion software is the correct default for most tactical work:

It matches the half-life of the question. If the business question is "how is this quarter's campaign performing," the right tool dies with the question. Building a permanent asset for a temporary question creates the legacy cruft that strangles every operating company in year five.
It lowers the cost of being wrong. Cheap, disposable artifacts are easier to throw away. That sounds trivial. It is not. The sunk cost of expensive software is one of the most powerful sources of organizational delusion ever built. Fast-fashion software has no sunk-cost defense.
It frees the long-lived layer for what actually compounds. When you stop treating every internal tool as inventory, you can spend serious time on the small set of things that genuinely deserve building once and maintaining well. The list is shorter than most teams admit, and clarifying it is half the value.

What you actually keep — the operator's compounding layer

The fast-fashion frame is only honest if there is something underneath it that does compound. That layer is small and deliberate, and it is the right thing to invest in seriously over years rather than weeks:

Your skill library. Twenty or so named, tested capabilities that you trust, version, and reuse across every fast-fashion artifact. This is the bet in The Skill Library—the part of the stack that gets stronger with each disposable tool you ship.
Your knowledge base. The personal LLM wiki that captures what worked, what failed, and why—covered in Personal LLM Knowledge Bases. Every disposable artifact deposits a learning here.
Your published thinking. Public writing, internal memos, repeated frames. This is the surface that lets the next operator compose on top of your work; the case is in A Public /writing.
The small set of true platforms. Identity, observability, data contracts, golden paths, a real design system. These are the genuinely-long-lived assets, and they deserve a different operating discipline than the campaign dashboard. The thesis underneath is in Why I Back Agentic Infrastructure.
Brand and taste. The hardest one to write down and the most important. Production is free now; judgment is rare. The frame is in Taste, Memory, and the Loop That Compounds.

When to refuse the fast-fashion default

The model breaks where the stakes change. Compliance systems, identity, money movement, customer data, brand voice, anything that signs in your name—these are not fast-fashion. Build them deliberately, version them publicly, document them like the long-lived infrastructure they are, and accept the higher cost as appropriate for the duty cycle.

The discipline is to tell yourself the truth about which mode this artifact is, every time. The failure isn't shipping fast-fashion software; it is shipping fast-fashion software in a situation that demands the long-lived treatment, or weighing down a seasonal microsite with the operating cost of a five-year asset.

What this asks of the team

Three cultural moves matter, in this order:

Stop treating tool-build as a project. Most internal tools should be built in a session, not approved on a slide. The approval process belongs to the small set of long-lived platforms.
Standardize disposal. Every fast-fashion artifact gets a tombstone date by default. If the operator wants to promote it to long-lived, that is a deliberate decision with a deliberate owner. The default is sunset.
Invest the saved time upstream. The time you reclaim from over-building tactical software is the time you spend hardening the compounding layer—skills, knowledge, taste, brand. That is where the operator's long-term value actually accrues.

Most software in the IC age is fashion: shipped fast, worn for a season, replaced when it goes out of style. That is not a failure of seriousness—it is a recognition of what the unit economics now allow. The compounding part of your work was never the artifact. It is the taste, the library, and the knowledge you build under each disposable thing you ship. Treat the artifacts lightly. Treat the layer underneath with absolute seriousness.