In the earlier parts of this series, I wrote about how much I wanted to learn.
I wanted to understand architecture, design patterns, microservices, scalability, and everything else that could make me a better engineer.
That hunger helped me professionally. It also created a problem in my personal projects.
I started thinking so far ahead that I often failed to finish what was directly in front of me.
Thinking about users I did not have
Understanding users has always been one of my strengths. At work, I talk to product managers, ask why a feature is needed, and try to understand how people will actually use it. This often helps me build something better than the first technical requirement suggests.
In personal projects, the same habit became difficult to control. I would start with a small problem, then imagine every person who might use the product. I thought about future features, large amounts of data, reusable components, and how the system might scale over the next ten years.
I was thinking about one million users before finding the first ten.
A meal counter that became too large
One project began with a simple problem in shared housing. In Bangladesh, bachelors and students often live together and manage their meals as a group. Someone needs to know how many people will eat each day so the cook can prepare the correct amount.
My idea was to create a small web portal where everyone could submit their meal count before a cutoff time. The cook might not be able to read or write, but she could understand numbers. Because of my robotics background, I also planned to put a small display on the wall showing the total number of meals.
That was enough. It could have solved a real problem in my own home.
Then I started talking to people and collecting more ideas. The app expanded into expense tracking, rent sharing, household accounting, and other features. I also started designing for scale, including reusable frontend components, backend architecture, and what the system might need if it reached a million users.
It never reached a million users. It did not even reach my own home.
The additional features were not useless. Many of them made sense. The problem was that I treated every possible future requirement as something I needed to solve immediately.
Building infrastructure before finding demand
Years later, I worked with someone else on a website-monitoring product. A user could submit a website URL, and the system would read its sitemap, check the pages, measure performance, and report basic SEO problems.
We were thinking mainly about small e-commerce businesses. Many had websites built by freelancers who were no longer available afterward. The owner needed a simple way to know whether pages were broken or slow.
The first version worked. That should have been the point where we focused on getting more users.
We had also received a large amount of free AWS credit, which changed how we approached the technical side. Cost was not limiting us, so the infrastructure became a playground of its own. We hosted Lighthouse ourselves, added monitoring, defined parts of the infrastructure through configuration files, and experimented with automatic scaling.
I learned a lot from that freedom, but it also made it easier to spend time on scale before we had proved the demand.
By the time the product reached a few customers, we had already invested heavily in solving technical problems that were not yet business problems. It did not gain enough interest, and around the same period, AI tools started changing how people approached website analysis.
The project taught me about AWS, infrastructure as code, monitoring, Next.js, and Lighthouse. I will write a separate technical post about what we built and how the system worked.
Still, as a product, it failed late. We could have learned much earlier whether enough people wanted it.
Six months trying to predict the market
Another project came from my interest in stock and crypto markets. I wanted to build a system that monitored hundreds of cryptocurrencies, detected unusual movements, and generated trading signals.
It began with the Binance API. Soon, I had separate services for collecting data, processing patterns, and generating signals. I tested mathematical methods, machine-learning approaches, language models, different market conditions, coin categories, timeframes, indicators, and formulas.
I worked on it for around six months. In the end, I could not find a method that produced consistent profit. A strategy might work during one period and fail during another. Without some informational advantage, short-term prediction looked unreliable.
This project was different because the experiment itself answered a question I had carried for a long time. I wanted to know whether I could build a dependable algorithmic strategy. After testing many approaches, I became convinced that I could not.
Perhaps I could have reached that conclusion with a smaller system. But at least this failure gave me a clear answer.
I plan to write a separate post about what I tested, what I found, and why I stopped believing that short-term market movement could be predicted consistently with a formula.
Why this rarely happens at work
I do not usually have this problem in my professional work. I still care about architecture, maintainability, and user experience. I still ask questions and think beyond the immediate task.
The difference is that work has deadlines. There are release dates, customers, teammates, and business needs. At some point, the feature has to ship.
Those limits help me decide which problems matter now and which ones can wait. I have built small scripts under tight deadlines, features that took several sprints, and larger MVPs that took months. I could still create maintainable code and finish before release.
The problem was not that I knew too much about software design. My personal projects had nobody to tell me when the current version was enough.
Good concerns at the wrong time
For a long time, I believed that learning more would make personal projects easier to finish. Sometimes it gave me more reasons not to finish them.
The components were not reusable enough. The data model might not support future growth. The services were too tightly coupled. The system needed better monitoring. The infrastructure would not handle enough users.
These were not imaginary concerns. They were real engineering concerns applied at the wrong time.
A project with no users does not need infrastructure for one million users. It needs someone willing to use the first version.
I still care about building software properly. I do not want to replace overengineering with careless work.
Good engineering is not only about preparing for the future. It is also about deciding which future problems are worth solving today.