Essay

Why “almost working” is the expensive state

Obviously broken software is easier to reason about. Half-working software can be more dangerous because it generates false confidence, delays hard decisions, and keeps teams paying for motion instead of clarity.

It is good enough to preserve, but not good enough to trust

This is the awkward middle where founders feel trapped. Throwing everything away feels reckless. Preserving everything feels naive. So the team keeps making local improvements without a strong diagnosis of whether the system beneath them deserves that investment.

It creates the illusion that one more push will fix it

Almost-working products invite optimism. That optimism can be useful early, but expensive later. Teams keep telling themselves that another weekend, another contractor, or another AI pass will make the app solid. Often what is missing is not one more push — it is a better decision framework.

It erodes trust more quietly than obvious failure

Obvious failure gives you a clean signal. Quiet unreliability gives you anxiety. When billing is technically live but still feels dangerous, or when deploys “usually work,” the result is not just technical debt. It is organizational hesitation.

The way out is not drama, it is diagnosis

The smartest move is often much narrower than a full rewrite and much sharper than continuing blindly. The hard part is getting a trustworthy read on what should be patched, what should be hardened, and what should be replaced before the team keeps building on top of uncertainty.