Problems don't hide. They get ignored.

When someone asks me how I choose what to work on, they expect a sophisticated answer. A method, a framework, some formula with a catchy name.

The truth is simpler and less comfortable: I don't go looking for problems. The ones that matter are already there, repeating every day, in front of everyone. The reason almost nobody solves them isn't that they're hidden. It's that nobody is seeing them anymore.

Blind to the everyday

A business loses customers because nobody answers WhatsApp after 6pm. A receptionist retypes the same appointment confirmation by hand fifteen times a day. A business owner checks four different notebooks to know whether there's stock. Nobody calls it "a problem" because it has been happening for so long that it has become part of the landscape.

That's the first filter I use: if something keeps repeating and nobody complains, it's not because it's solved. It's because it has become invisible.

Complaints show up when something is new. What really hurts, the chronic stuff, doesn't even get mentioned. It gets absorbed as part of the cost of running a business. And that's exactly where it's worth looking before thinking about what to automate first.

You don't need to invent the problem

There's a strong temptation, especially when you start building products, to go out looking for "interesting" problems. Problems that sound good in a pitch. The trap is that many of those problems don't exist for anyone except the person who invented them.

I prefer the opposite: walk into real businesses (a clinic, a salon, a barbershop, a real estate agency) and ask not "what do you need" but what are you doing by hand that shouldn't be done by hand anymore. That question almost never fails. There's always an answer, and it's almost always the same across different businesses of the same kind.

That tells me something important: if a problem repeats across several similar businesses, it's not an isolated annoyance. It's broken infrastructure at scale.

What I won't share yet

I'm not going to share here the exact map I use to decide what to build first, or the criteria I apply to discard an idea before writing a single line of code. That part of my process is still being refined, and I'd rather show it with results than explain it in the abstract.

What I can say is this: most people looking for "the next big idea" are looking too far away. The real opportunities, especially in Nicaragua and Latin America, aren't hidden in some untouched market. They're right in front of us, disguised as normal, in processes a business has been doing poorly for years because it never had anyone to do them differently with.

The stance, not the recipe

If there's one thing I want this blog to make clear, it's not a list of tools or a tutorial. It's a way of looking: the problem worth solving is almost never the one that shouts. It's the one nobody notices anymore.

That stance guides everything I'm building right now. The details (what, how, which stack) you'll see in the case studies, as they actually come to exist and not just as ideas.

For now, keep the question. Apply it to your own business, or to someone close to you: what are they doing by hand, every day, that shouldn't be done by hand anymore?

That's almost always where the problem worth solving is.