It's common to see developers spend entire days searching for sub-niches inside programming: wanting to create the next PostgreSQL, a language faster than Rust, or one more object-oriented than C++.

There is nothing wrong with that. Someone has to do it.

However, in this article I want to explore vertical markets in depth: what they are, how to approach them, and why they represent a concrete opportunity, especially now that artificial intelligence is significantly lowering the technical barrier to entry.

A few days ago, the Sequoia Capital team published an article arguing that the next billion-dollar company will be the one that manages to disguise software as if it were a service.

But this is not new, at least not in Latin America, and that gives us an advanced position on the board.

In the region, consumers have historically preferred hiring services instead of buying products. For those of us who have spent years building software and offering services, that represents an experience vector that should not be underestimated.

To understand why this is not a recent trend, it is worth going back to Clayton Christensen and his book The Innovator's Dilemma. The central thesis is that established companies fail not because they are incompetent, but because they optimize so well for their current markets that they end up ignoring the emerging markets around them. The parallel with our industry is direct: it is easy to get trapped in the technical depth of an ecosystem and lose sight of how many traditional markets still have not been touched by software.

What is a traditional market?

The remora is a fish that attaches itself to the body of sharks and other larger species. It does not compete with them. It does not threaten them. It feeds on the waste they generate and in return offers them cleaning. It is a relationship where both sides win, and the remora thrives precisely because it chose to attach itself instead of competing.

That image describes very well what a traditional market is and the role we can play in it.

A traditional market is an established, mature, pre-existing segment where conventional companies operate with proven business models, linear growth, and low risk. These are industries that have been functioning for decades: logistics, construction, cattle farming, local retail, professional services.

As software founders, we can attach ourselves to these companies. We offer them a service that does involve risk, that does aim for exponential growth, but that stands on top of proven business models with returns that are already measurable. We do not need to invent the problem. The problem already exists, it already hurts, and there is already someone willing to pay to solve it.

This is not new: the case of graphic design

Maybe we already take it for granted, but it is worth grounding it in a concrete case: an industry that today is deeply tied to software, but that for decades operated completely without it, and that already has two benchmark companies with IPOs.

Graphic and product design is that case.

For years, designers worked with physical tools: paper, pencil, set squares, markers, and light tables. The process was manual, slow, and difficult to iterate on. Then digitization arrived, and with it tools like CorelDraw and Adobe Illustrator in the 80s and 90s, which moved that workflow to the screen without changing too much of the underlying logic. Adobe ended up becoming the standard for decades with its full suite, from Photoshop to InDesign, and it went public in 1986.

But the market was not solved. Sketch appeared in 2010 and started displacing Adobe in digital interface design by being lighter and more focused. Then Figma arrived in 2016, took that same market fully into the cloud, added real-time collaboration, and eliminated the friction of local files. Figma filed for IPO in 2025.

Nobody invented the need to design. That need existed before computers did. What each of these products did was attach itself to a traditional market, understand its frictions, and solve them with software.

That is exactly the pattern we are discussing.

Why now?

Today more than ever, code quality has stopped being the central priority. Some more purist developers will point out that technical debt eventually comes due, and they are not wrong. But for someone evaluating whether to enter a traditional market with a software service, that is a fair price to pay.

What matters most is entering the market.

Artificial intelligence has compressed the time between an idea and a functional product in a way that would have been unthinkable just a few years ago. A founder without a team can now build, deploy, and charge for a service in weeks. That changes the calculation completely: the risk is no longer whether you can build it, but whether the market needs it. And in traditional markets, that second question already has an answer.

Christensen described disruption as a slow and costly process, reserved for companies with enough capital and enough time to wait. That description no longer applies. The very industries he studied, where incumbents ignored the signals because they were optimizing for what already worked, can now be entered by a founder with an LLM subscription and clarity about the problem they want to solve.

How to recognize it and execute on it

I do not have a scientific answer for knowing when you are facing a traditional market. Personally, I go by something much more intuitive: the moment of "I could do this better."

It is the instant when you interact with the internal software of a traditional company, or with the manual process they use because nobody ever offered them something better, and as a programmer you feel that you could solve it more efficiently. That thought is the signal. Once you start investigating, you discover that the only options that exist are incumbents: companies that have been operating for decades, with outdated interfaces and no real incentive to innovate because they have no competition forcing them to.

That is your moment.

The product as an entry point, not a destination

What comes next is simpler than it looks. Creating a product is comfortable; there is something satisfying about building a clean interface and a well-documented API. But that is not what the traditional market is buying.

Sequoia puts it directly: for every dollar spent on software, six are spent on services. The budget is not in the tool, it is in the work. A company does not want to pay for the software that closes its books, it wants its books closed.

That initial naivety is not a flaw in the process, it is part of it. If you knew from the beginning the real complexity of what you were facing, you probably would never enter. And LLMs make this viable for a solo founder: what used to require an operations team behind the software can now be automated enough that you can commit to the result, not just the tool.

How to enter a market you do not know

There is an apparent contradiction in everything I have said so far: if the goal is to sell a service, how do you offer a result in an industry you do not understand?

The short answer is that you cannot. And that is where the product starts making sense again, but with a different role.

The MVP as an excuse to listen

When I entered the automotive world and the restaurant world, I had no idea how they worked internally. I did not know what their processes were, where the real friction was, or what they would be willing to pay for. What I could do was build something concrete and take it to someone in that market. A product, even a basic one, gives you an excuse to sit down with a customer and listen.

That is the real function of the MVP in a traditional market: not to validate whether you can build it, but to get access to the people who are going to teach you how the industry works.

The friction outside your product

Once you are inside, the work changes. You are no longer iterating based on direct feedback, you are looking at the processes outside your tool: what the client does before using it, what they do afterward, where they lose time, what they solve with another person or with an Excel sheet because your solution does not reach that far.

That friction that exists outside your product is where the service lives. And it is what eventually replaces the MVP as the value proposition.

The map we use has edges

The developer who opens this article looking for the right sub-niche inside programming will probably keep looking after they close it. That is fine too. But if at some point they feel that the map is exhausted, that technical niches are getting more and more crowded, and that differentiating inside the ecosystem gets harder and harder, it is worth remembering that this map covers only a small fraction of the territory.

It was drawn by developers, for developers. And by definition, it excludes everything outside that perspective.

What does not show up on Hacker News

Most industries in the world do not have a Stack Overflow equivalent where people publish their problems. They do not have a founder who wrote a thread explaining how they solved their billing process. They do not have early adopters who already understand the value of what you offer, or a community that amplifies your launch.

They operate with the tools they got years ago, with the processes that worked when they were smaller, and with the resignation that this is simply how things work in their sector. They are never going to open a GitHub issue asking someone to come solve their problem. They are never going to post on Product Hunt. They do not even know their problem has a solution.

Resignation as an opportunity

That resignation is not an obstacle. It is the opportunity.

When an industry has spent decades operating with the same tools and the same processes, it is not because its problems are unsolvable. It is because nobody who knew how to solve them took the time to look in that direction. The incumbent dominating that market does not innovate because it has no competition forcing it to. And it has no competition because everyone who could compete is looking inward, searching for the right sub-niche inside an ecosystem they already know.

Outside, by contrast, the developer who arrives first does not need to be the best. They only need to be the one who showed up.

Outside was always there

Everything I described in this article, the MVP as an excuse to listen, the friction outside the product as the place where the real service lives, the result as the value proposition instead of the tool, points to the same thing: the most interesting work is not in building the next layer of technical infrastructure, but in bringing software to places where it still has not arrived.

Those places do not advertise themselves. They do not send signals. They do not have a community waiting for someone to solve them. They are there, operating the same way they always have, with the same resignation as always.

And they will keep being there until someone decides to stop looking inward for long enough to see them.