4. Two Models: The Tip of the Pyramid vs. The High Average

There are two profit models in the world. One follows the 80/20 rule, where the top 20%—or, more extremely, the top 1%—capture 80% of the profits. The other offers a high average return, meaning you don’t necessarily have to be an outlier to do well.

For decades, software development has belonged to this second model. You don’t have to be among the absolute elite to earn a very good living—a characteristic it shares with professions like medicine and law.

What defines these professions is that they require years of study, intense skill development, and deep expertise. More importantly, there must be a market capable of sustaining the supply. Although the rise of LLMs has dramatically lowered the barrier to writing code and building things, the underlying demand for software development remains strong. We’ll dive deeper into that topic later.

Many industries feature this kind of pyramid structure. In software development, profits depend on the success of a company’s business model, rather than the act of developing software itself. In other words, a product’s success doesn’t always come purely from having brilliant software—many other factors are at play.

As long as you join a company whose business model sits at the upper tier, you aren’t restricted to a single industry track. This makes the overall market capacity for software development enormous. At the same time, software possesses several advantages that are hard for other industries to replicate:

• Increases in computing power continuously lower the barrier to software development.
• Low development costs: While it depends on the software’s complexity, anyone with a computer can start writing code.
• Virtually zero upfront costs: For early-stage traffic, most services offer free tiers. At most, you pay for a domain name (around $10 a year).
• High scalability and ease of replication: A single piece of software can be sold to an infinite number of users.

On the other hand, there is the winner-take-all model: influencers, authors, artists, athletes, and the like. Outside of the tiny group at the very top of their field, most people can’t support themselves without a side hustle. Freelancing might pay the bills, but it rarely produces compounding returns. (This is strictly from a financial perspective; if your goal is self-actualization and passion, pursue whatever you want.)

I was fortunate enough to spend the first ten years of my career inside a pyramid defined by the second model.

Indie hacking, however, is a completely different story. Beyond understanding the development process, you have to handle everything on your own: the product, the market, and the business model. These require substantial accumulation, research, and sharp market intuition—none of which happen overnight.

I once read about a case online: for a traditional massage parlor, the best booking system was simply a phone and a notepad. They didn’t care at all about automation, online booking, or web exposure. You might think building them an automated, online scheduling tool solves a real problem, only to realize after building it that it was entirely your own fantasy.

Industry rules often seem deceptively simple from the outside, making you feel you could easily jump in and do it yourself. But without the right resources—perhaps failing to reach the key decision-maker, struggling to navigate regulations, or facing an inherently insular circle—your engineering skills alone won’t get you anywhere.

Having personally benefited from networking and resource integration, I know just how crucial this is. While an indie dev worries about saving on server bills, someone else can make a single phone call and get them for free. When legal help is needed, one call connects them with a dedicated partner firm. The execution efficiency of that kind of leverage leaves a beginner in the dust.

When you have to figure everything out on your own, you are suddenly thrust into a pyramid operating under the first model. But that’s okay—you can make that pyramid smaller in a couple of ways:

• Narrow your niche: Shrink your target audience until it’s small enough for you to reach the top. For example: health drinks specifically for new mothers; Netflix for indie musicians; a social platform dedicated to fandom support (oshi-katsu).
• Validate ideas quickly at low cost: Don’t write code first. Use group sign-ups, Google Forms, landing pages, MVPs, or prototypes to confirm demand.
• Find the key players and tap into resource networks.

Another thing to keep in mind along this journey is that many people will doubt or dismiss your ideas. Some of their feedback will be genuine insight; other times, it’s simply because they are not your target audience (TA).

There is a big difference between rushing for shortcuts and validating ideas quickly. Taking shortcuts means expecting results without putting in the work. Rapid validation means confirming demand with minimal cost before committing significant time and energy to build.

I don’t consider myself the next Steve Jobs. I can’t accurately predict what users want out of thin air and build a mesmerizing product with no preexisting demand. However, I believe that building through iterative practice refines your instincts along the way.

Some might argue that this approach lacks developer craftsmanship—that we should polish product details obsessively, like Apple does. But talking about craftsmanship out of context is far too idealistic.

If I had virtually unlimited capital, I would gladly polish a product at my own pace until it felt perfect. But that is not my reality. Approaching work with a craftsman’s mindset is truly admirable, but it also carries the real risk of starving.

Survival comes first.