The problem must come before the technology

A product is not born from a framework

When someone asks for an app, a dashboard or an automated system, the easy response is to start thinking about screens, tables, APIs and tools. That part is exciting, but it can also become a trap. A product can be technically correct and still fail because it was built around the request instead of the problem.

I try to slow the beginning down. Who is affected? What happens today? Which steps are painful? Which decisions are delayed? What must still work when the network is weak, the device is old or the user is under pressure? These questions shape the product more honestly than choosing a technology too early.

The workflow teaches the architecture

Real workflows reveal dependencies that are invisible in a meeting. A person may repeat the same data entry because two departments do not share information. A business may lose clarity because sales, stock and payments are recorded in different places. A team may ask for automation when the deeper need is a simpler process.

That is why I see discovery as engineering work. The structure of the problem helps decide whether the solution should be a full system, a small internal tool, a PWA, a report, an integration or sometimes no new software at all.

Better questions protect the build

Starting with the problem does not make development slower. It prevents speed in the wrong direction. A clear understanding of the situation helps reduce unnecessary features, define useful scope and build something people can trust in their normal environment.

For me, technology is most valuable when it becomes a practical improvement: a clearer workflow, better information, less manual repetition or a new possibility that was difficult before.

Build with the same care

Have a product, workflow or system worth thinking through?

I like starting with the real problem, the people around it and the constraints that shape the work.

Start a conversation More insights