How Running Small Products Changed the Way I Think About Software

For a long time, I looked at software mainly from an engineering point of view. A feature had requirements, I had to build it properly, the UI needed to work, the API had to respond, and the code should be maintainable. That mindset helped me grow as a software engineer, but running my own small products changed how I think about software.

When you build something for yourself, put it in front of real users, charge money for it, receive complaints, change pricing, and decide what to build next, software stops being only a technical project. It becomes a business problem, a user problem, and sometimes an operational problem.

Building Features Is Not the Same as Building a Product

As developers, it is easy to get excited about features like dashboards, analytics, automation, notifications, and advanced architecture. But users do not care how many features you have. They care whether the product solves their problem.

I learned this while working on Keepur, an inventory management platform for small businesses. From an engineering point of view, there are many things we could build: advanced reporting, serial-number tracking, manufacturing modules, integrations, automation, and more. But real users often ask much simpler questions: Can I track my stock? Can I see today's sales? Can my employee use the system? Can I send an invoice? Can I understand the software without training for hours?

That changed the way I think. Instead of asking, “What feature would be cool to build?” I started asking, “What problem is stopping someone from using or paying for the product?”

Real Users Expose Real Problems

You do not need thousands of users to learn. Even one paying user can show you problems that you never noticed during development. A confusing button, a subscription issue, an incorrect stock calculation, or a small bug suddenly becomes important when someone depends on your product every day.

With Keepur, I started thinking more seriously about subscription states, trial expiry, inventory workflows, SMS invoices, serial-number tracking, and how a shop actually operates. These are not flashy portfolio features, but they are the things that make software useful.

That taught me to respect boring problems. Very often, the boring part is the actual product.

Festivo Taught Me to Think About the Full Workflow

I had a similar experience while building Festivo, an event and ticketing platform. At first, the product sounds simple: create an event, sell tickets, generate QR codes, and scan them at the entrance.

But when you think like a product owner, more questions appear. What if there are multiple ticket types? What if there is a discount? How does the organizer see attendees? Can they import attendees? What happens for multi-day events? Who manages the event? What does the organizer need after the event?

Suddenly, you are not building a ticket page. You are designing an operational workflow.

That was an important lesson for me: a feature exists on a screen, but a product exists inside someone’s real-life process.

Clients Often Describe a Solution, Not the Real Problem

Working with clients through Dellly taught me something similar. Clients often say things like, “We need a dashboard,” “We need an approval system,” or “We need an app like this one.”

The easy thing is to estimate the screens and start development. The better approach is to ask why they need it, who will use it, what happens before and after the action, who has authority, and what happens when something goes wrong.

Once you ask those questions, the project usually changes. Sometimes you discover missing requirements. Sometimes you remove unnecessary features. Sometimes the original idea is too complicated, and sometimes the best solution is much simpler.

This is why I now care much more about understanding the problem before touching the code.

Small Products Force You to Think About Money

Software is not free to run. Servers cost money. SMS costs money. Payment gateways charge fees. Support takes time. Development takes time. Customers compare pricing.

As an engineer, the question is often, “Can we build this?”

As a product owner, the question becomes, “Should we build this?”

That difference matters. A feature may be technically possible but commercially pointless. If only a few users need it and it takes weeks to build, it may not be worth it. A much simpler feature that helps most paying users may create more value.

Technical feasibility is only one part of product development. Commercial value matters too.

I Started Respecting Simplicity More

Earlier, I often thought more features meant a better product. Now I think differently. Every feature adds more code, more bugs, more testing, more support, more documentation, and more decisions for the user.

So I now ask different questions: What is the smallest workflow that solves the problem properly? What can we remove? What can be manual in the beginning? What does not need to exist in version one?

A good MVP is not a badly built version of a big product. It is a deliberately small version of the right product.

Technical Quality Still Matters

Running products did not make me care less about engineering. It made me care about engineering for better reasons.

Clean architecture matters because the product will change. Testing matters because users depend on the system. Logging matters because something will eventually fail. Good database design matters because business requirements will evolve. Documentation matters because more people may work on the product later.

Technical quality becomes much easier to justify when it is connected to real product needs.

AI Makes Product Thinking Even More Important

AI is making software development faster. We can now prototype products much faster than before. That is powerful, but it also means we can build the wrong thing faster.

The bottleneck is changing. Writing code is not always the hardest part anymore. Understanding what should be built is becoming more important.

That means engineers need more than coding skills. We need product thinking, business understanding, communication, and the ability to understand users and tradeoffs. AI can help with implementation, but it cannot automatically understand every user, business constraint, and operational reality.

Judgment still matters.

The Biggest Change in How I Think

Running small products did not make me less interested in engineering. It made me look at engineering differently.

Earlier, my mindset was: build the feature correctly.

Now it is: understand the problem, decide whether the feature should exist, build the simplest correct solution, put it in front of users, learn, and improve.

That is a much bigger loop than development alone.

And that is probably the biggest lesson I have learned from building and running my own products.

Because at the end of the day, nobody buys your code. They buy the problem your code solves.