Recently, I found myself looking through some of the projects I've worked on over the past few years. Some are still active, some have evolved far beyond their original idea, and quite a few never made it into the world at all. As I browsed through old code, product notes, and screenshots from earlier versions, something struck me: I remembered very little of the technical implementation. There were entire modules, functions, and components I had completely forgotten about. What I remembered instead were the decisions.
For a long time, I thought building software was primarily about implementation. That is a natural assumption when you start your career as a developer. Progress appears tangible when something new is added: a screen, an integration, a capability that did not exist before. Over time, though, I started noticing that a significant part of the work happens before a single line of code is written, and another equally important part happens when you decide what not to build.
In Founder, for example, there were several game mechanics that sounded promising when I first imagined them. Some were fully implemented and worked exactly as intended. The problem was that they made the game harder to understand without making it more enjoyable to play. I ran into similar situations while working on AppGrid. Certain ideas looked useful on paper but introduced additional concepts, steps, and explanations that moved the product further away from its core purpose. The challenge was not getting those features to work. The challenge was recognizing that the product was better without them.
That part of product development is largely invisible. Users only see what remains. They do not see the alternatives that existed before, the abandoned directions, or the discussions that led to a particular decision. When a product feels simple, there is often a surprising amount of work hidden beneath that simplicity. Not because the implementation was especially difficult, but because someone spent time questioning every element and asking whether it truly needed to be there.
This is one reason I find it difficult to measure progress by the amount of code written. There are weeks when I write a great deal of code and feel as though the product barely moved forward. There are also days when I remove a feature, simplify a workflow, or rethink a concept and end the day feeling that the product improved significantly. The difference is that the most important work is not always about building more. Very often, it is about understanding the problem more clearly.
The rise of AI tools has made this even more apparent to me. Writing code has become faster. Prototyping has become easier. Many tasks that once required days of effort can now be completed in hours. Yet the bottleneck has not disappeared. It has simply moved. The difficult questions remain the same: Are we solving the right problem? Are we making the experience better or just adding more functionality? Are we creating something people genuinely need, or are we building something that is merely interesting from a technical perspective?
Looking back, I remember fewer and fewer implementation details and more and more of the process that shaped the product. I remember changing direction after discovering a flawed assumption. I remember removing features that I once considered essential. I remember refining an idea through multiple iterations until it finally felt right. Those moments seem to stay with me much longer than the code itself.
Perhaps that is because products are not really defined by the features they contain. They are defined by the thousands of decisions that shape them over time. And when I look back years later, it is those decisions—not the code—that I remember.
Related Sparkio Products
Founder Interactive business history simulator inspired by the stories and decisions behind the world's most influential companies.
AppGrid Platform designed to help independent developers connect their products with potential customers.