Starting With the Problem, Not the Technology

When I think about building a new product, my first question is not What technology should I use?

It is:

What problem are we actually trying to solve?

Technology can make a solution faster, more scalable, or easier to use. But choosing technology before understanding the problem can also lead to building something technically impressive that does not solve what people actually need.

This has become an important principle in the way I approach my own projects.

Understanding the situation first

Before thinking about frameworks, databases, interfaces, or automation, I try to understand how the current process works.

Who is experiencing the problem?

What are they trying to accomplish?

What makes the current process difficult?

What constraints exist in the real environment?

Those questions often reveal requirements that would be easy to miss if the conversation started with technology.

A solution that works perfectly in an ideal environment may fail completely when it meets real operating conditions.

Constraints are part of the product

I encountered this clearly while thinking about MST, a retail management system for a small store.

It would be easy to begin by designing a conventional cloud-based inventory application. But the real environment introduces an important constraint: internet connectivity cannot always be assumed.

That changes the architecture of the product.

Instead of treating unreliable connectivity as an inconvenience to solve later, it becomes a core requirement. The system needs to remain useful offline and synchronize when connectivity becomes available.

The technical decision comes from the operating reality—not the other way around.

Different problems require different systems

The same reasoning appears in other projects.

With R Financial, the challenge is not simply storing financial transactions. People already have bank statements and financial data.

The more interesting problem is turning scattered information about income, expenses, debts, subscriptions, payments, and other obligations into something understandable enough to support better decisions.

With SANG, the problem is different again.

The goal is to structure the coordination of a rotating savings process: participants, contributions, payment cycles, payouts, and the responsibilities of the organizer.

Each project involves technology, but technology is not the starting point.

The process is.

Technology becomes a consequence of understanding

Once the problem, users, workflow, and constraints become clearer, technical decisions become easier to justify.

Should the application work offline?

Does the information need to synchronize?

What data needs to be preserved?

Which actions need to be simple?

Where can errors create serious consequences?

What should be automated, and what should remain under human control?

These questions connect product thinking with system design.

Instead of asking which technology is the most impressive, I can ask which technology best supports the requirements that have already been identified.

Building better questions

I am still learning this process.

But one lesson continues to become clearer as I work on different systems:

Good solutions often begin with better questions.

Understanding the problem does not eliminate technical complexity. It gives that complexity a purpose.

For me, that is becoming one of the most important differences between simply building software and designing a useful system.