The Bottleneck

For the past two months I’ve been working on an e-commerce marketplace product. Two hours every weekday and at least five hours on weekends. And I’m still not done with V1.

A friend of mine found this mind-boggling. With LLMs generating entire apps over a weekend, he couldn’t understand why I was still working on the first version months later.

What's taking you so long?

It’s a fair question. But it misses something important.

Code was never the real bottleneck. Even before AI.

Successful software products are far more than just the code. Someone has to think through the system, design the architecture, and make trade-offs that fit the use case. There’s infrastructure to set up, monitoring to configure, and deployment pipelines to manage. And eventually something will break — so you need to know how the system behaves when it does.

All of that work sits outside the code.

That’s the difference between software that simply runs and software that survives the real world.

Pivot To Software

Before pivoting Dot Dot Portal toward software development, most of my work was website design. When I started building my first product, I realized quickly that writing code alone wouldn’t be enough. I needed to understand system architecture and design.

More importantly, I needed to understand the problem domain. In traditional development teams, there are often domain experts shaping the solutions engineers eventually implement. But when you’re building solo, you wear every hat.

Before starting this project, I didn’t know much about online commerce. So I spent a lot of time researching the domain — how orders flow through a system, how inventory behaves, how payments interact with fulfillment, and where things usually break.

There are days when I open my laptop and don’t write a single line of code. I just read, sketch ideas, rethink assumptions, and adjust the design.

Prompt AI

Could I prompt my way into a working product with AI? Probably. But commerce is not a toy project. When money is involved, mistakes become expensive very quickly.

So understanding the system deeply isn’t optional. It’s required. I could bring in another developer to move faster. But for now I’ve decided to keep building solo. It’s not only more affordable, it also forces me to understand every layer of the system.

It also gives me a clearer sense of what good engineering work looks like — something that will matter if I’m managing a team later.

Another factor is uncertainty. I still don’t know if the solution I’m building is the right one. The design keeps evolving as I learn more about the domain and discover better approaches.

Because of that, it makes more sense to stay lean until the product reaches product-market fit.

So yes, progress might look slow.

But deep understanding is what enables speed later.

Because when you truly understand how the system works, AI becomes an accelerator. Not a shortcut.

Credit: cover photo is a 3D cartoon of me at the office done by AI.

— Umaru