Some years ago, I worked for a company where my task was to create an Android application for logistics purposes. It was an experimental project.
The company didn't use version control. Most of the functionality was implemented in Perl scripts and ad hoc PHP files connected to PostgreSQL databases through stored procedures and views. Reporting was handled by JasperReports. The core applications were built using custom scripts without any object-oriented design.
When I first saw the codebase, I was surprised. Even more surprising was the fact that the system had been working for years.
The lead developer was also one of the CEOs. One day, he asked for my opinion about the architecture and development practices. I spent an entire weekend preparing a presentation and carefully documenting my observations.
On my next workday, I presented my findings.
That turned out to be my last day at the company.
Looking back, I learned an important lesson. Perhaps my communication could have been better. Perhaps the CEO was not ready to hear criticism of something he had built himself. Either way, the experience taught me how difficult it can be to accept feedback about our own work.
And that lesson applies far beyond software architecture.
Feedback is essential. Without it, we cannot grow, learn, or improve. This is true for individuals, teams, products, and entire companies.
Recently, I read a Reddit discussion about a developer who spent countless hours and a significant amount of money building a product. Despite all the effort, the product failed to gain traction. The market simply wasn't interested.
I believe this is a very common scenario.
Today, many developers are building products in an AI-powered world. With AI coding assistants and modern development tools, creating software has never been easier. Applications that once required months of work can now be built in days or even hours.
As a result, many people focus heavily on building. They create one application after another, publish them online, share them in forums, and hope users will discover them.
The problem is that building is no longer the hard part.
Many creators build something they personally find exciting and only afterward try to find customers for it. Unfortunately, customers rarely care how much effort went into a product. They care whether it solves a problem they actually have.
This is where the connection to my earlier story becomes interesting.
The CEO struggled to accept feedback about his software. Many founders struggle to accept feedback from the market. In both cases, someone becomes emotionally attached to what they have created and starts defending it instead of learning from criticism.
The result is often the same: missed opportunities for improvement.
Of course, there is nothing wrong with building projects for learning, experimentation, or personal enjoyment. Not every project needs to become a business.
However, if your goal is to create a profitable product, then validation must come before development.
Have you ever considered what happens when everyone can build software quickly using AI tools? If almost anyone can create an application in a short amount of time, then building is no longer a competitive advantage.
Ideas alone are not valuable if there is no demand.
The real challenge is understanding market needs and validating assumptions.
Can you validate your idea before investing months of effort?
What experiments can you run?
What can you learn from the results?
And perhaps the most important question: are you willing to change your assumptions when the evidence tells you that you should?
The goal is not to build the product you want.
The goal is to build the product the market needs.
That is why validation, customer interviews, experiments, and feedback loops are so important. They help us replace assumptions with evidence.
To support this process, I created a website that collects and organizes market demands. It allows you to see what people within a specific niche are discussing, struggling with, and actively looking to solve.
I call it the Pain Point Monitor.
The idea is simple: instead of guessing what people need, you can observe real problems and real demand. In a rapidly changing world, it can serve as a compass for entrepreneurs, developers, and creators who want to build products that people actually want.
Feel free to check it out, and of course, I appreciate any feedback. After all, feedback is where this story began.
