For most of my career, I assumed that building software was the hard part.
That belief made sense. Writing code requires technical skills, experience, and a willingness to spend hours solving problems that are often invisible to everyone else. It is challenging work, and for many years I focused almost entirely on improving that craft.
What I did not fully appreciate was that building a product and building a business are two different activities.
A product can exist without users.
A business cannot.
Over the last year, while working on several side projects, I started to notice a pattern. Adding a new feature was usually straightforward. Sometimes it took a few hours. Sometimes it took a few days. Either way, progress was visible and measurable.
Finding people who cared about that feature was much harder.
There is a certain comfort in development work. When you are coding, you know what success looks like. The feature works, the tests pass, and the deployment succeeds. You can point to something tangible and say that progress was made.
Distribution is different.
You can spend weeks writing content, talking to potential users, refining your message, and still feel as if nothing is happening. The feedback loops are slower. Results are less predictable. Progress is harder to measure.
For technical founders, that uncertainty can be frustrating.
The natural reaction is often to return to the product.
If users are not arriving, perhaps the application needs another feature.
If adoption is low, perhaps the design needs improvement.
If engagement is weak, perhaps a new workflow will solve the problem.
Sometimes those assumptions are correct. Often they are not.
A mediocre product with excellent distribution frequently outperforms a great product that nobody knows exists.
That is not a pleasant reality for builders, but it is reality nonetheless.
One of the lessons I have learned is that software development provides a feeling of productivity that can be misleading. It is possible to spend months improving a product while avoiding the uncomfortable work of talking to users.
I have done that myself.
Building feels productive because something changes every day. Distribution often feels unproductive because results arrive much later.
The challenge is that users do not experience your effort. They experience your product. If they never discover it, the quality of the implementation becomes irrelevant.
This realization changed how I think about side projects.
Instead of asking what feature should come next, I increasingly ask a different question:
Who should know about this product, and how will they discover it?
That question leads to activities that many technical people tend to avoid. Writing articles. Talking to potential customers. Understanding how people currently solve a problem. Learning how they search for solutions. Listening to objections.
None of those activities produce code.
All of them influence whether a product succeeds.
Interestingly, the more I speak with users, the more I realize that distribution and product development are not separate disciplines. The conversations that help people discover a product are often the same conversations that reveal what the product should become.
Users explain their frustrations. They describe their workflows. They tell you what matters and what does not. Those insights improve both the message and the software itself.
The best products are rarely built in isolation.
They emerge from an ongoing dialogue between builders and users.
Looking back, I no longer think building software is the hardest part of creating a product. It is certainly difficult, but it is also the part many of us enjoy the most.
The harder challenge is earning attention in a world filled with alternatives. That requires patience, consistency, and a willingness to spend time outside the editor.
Software can be built in weeks.
Trust often takes months or years.
The founders who understand both sides of that equation usually have a much better chance of turning products into businesses.