There is a category of engineering work that feels productive but produces no value. Building features that are not shipped. Polishing systems that users cannot see. Refactoring code that already works. Planning architectures for requirements that do not exist yet.
I have done all of these things. They feel like progress because they involve effort and produce artifacts. But an unshipped feature and a deleted feature have the same user impact: zero.
Inventory costs
In manufacturing, inventory is a liability. Parts sitting in a warehouse are capital that could be deployed elsewhere, degrading over time, requiring storage and tracking. The lean manufacturing insight was that inventory is not an asset. It is waste that has not been recognised yet.
Software has the same dynamic. Unshipped features are inventory. They sit in the codebase, accumulating merge conflicts, falling behind API changes, growing stale relative to the product they were built for. Every day they are not shipped, they cost more to ship. And the user, who would have benefited from them weeks ago, receives nothing.
The polish trap
The most common form of inventory accumulation is the polish trap. The feature works. It is tested. It handles edge cases. But it is not "ready" because some detail is not perfect. The animation is not smooth enough. The error message could be better. The loading state needs another pass.
These concerns are real. Quality matters. But there is a question that too few engineers ask: is the user better served by the polished version next month, or the working version today?
In most cases, the answer is today. The working version generates feedback. Feedback reveals which parts of the polish actually matter and which parts were aesthetic preferences disguised as quality concerns. Shipping creates information. Polishing consumes it.
The AI magnifier
This dynamic is amplified in AI products because the product improves with use. Every user interaction generates data about what works and what does not. An AI marketing platform that is live and processing real campaigns learns faster than one sitting in staging. The model's effectiveness improves with exposure to real-world patterns. The context assembly gets better with real data. The edge cases you discover in production are always different from the ones you imagined in development.
Not shipping delays this learning. And in a market where every AI product is improving rapidly, delayed learning is a competitive loss that compounds.
Discipline, not recklessness
Shipping fast is not the same as shipping carelessly. The security checks still matter. The data integrity guarantees still matter. The authentication and authorisation still matter. These are not polish. They are structural requirements that protect users and the business.
The discipline is distinguishing between structural requirements that must be met before shipping and aesthetic preferences that can be addressed after shipping. The first category is small and non-negotiable. The second category is large and should be informed by real usage data rather than internal speculation.
A useful test: would this issue cause harm to a user or their data? If yes, fix it before shipping. If no, ship and observe.
What I learned building alone
Building as a solo developer forced this discipline on me. When you are the only person building, every hour spent polishing a shipped feature is an hour not spent building the next feature that users need. The opportunity cost is not abstract. It is visible on your calendar.
I shipped features that were not perfect. Some of them turned out not to matter at all, and I saved weeks of polish work on something users never used. Others turned out to matter enormously, and the early feedback shaped them into something better than my original design.
The features I delayed, waiting for perfection, taught me nothing until they shipped. The ones I shipped early taught me everything I needed.
The cost of not shipping is invisible. That is what makes it expensive.
- Cleo's Team