How I built two profitable apps without being a developer

I did not set out to become an app developer

I started playing with AI-assisted development because I was curious. That is the honest version. There was no dramatic founder moment and no pitch deck with a hockey-stick graph hiding in a folder.

I had spent years working around operations, learning, capability and technology. I could see problems. I could describe how people behaved around those problems. What I could not do was turn an idea into software without handing the whole thing to somebody else.

AI changed that first barrier. It gave me a way to ask questions, make something, break it, fix it and slowly understand what was happening. That curiosity became one app, then another. Both now have real customers and make money. I still do not introduce myself as a developer.

The demo was the easy bit

The first working screen feels like magic. You describe something, wait a bit and suddenly there is a button doing roughly what you asked. It is very easy to mistake that moment for having built a product.

A product has users, awkward edge cases, support messages, privacy decisions, subscription failures, analytics, app-store requirements and things that only break late at night when you were planning to go to bed.

AI made the distance between idea and demo much shorter. It did not remove the distance between demo and useful business. That second distance is where most of the learning happened for me.

I started with one useful path

My best product decisions have usually involved removing something. A first version does not need to prove the entire vision. It needs to let one real person complete one useful path without you standing beside them explaining what every button was meant to do.

That means choosing a narrow customer, one recurring problem and the smallest outcome that would genuinely matter. Not a landing page pretending the feature exists. A complete path, however small.

The smaller path also makes AI easier to direct. Instead of asking it to ‘build my app’, you can describe the user, the job they are trying to complete, what information is needed and what success looks like. Better context beats a bigger prompt every time.

• Choose one person with one repeated problem.
• Write the one action they should be able to complete.
• Build that path from beginning to end.
• Put it in somebody else’s hands before adding more.

I learned enough to stay responsible

You do not need to become a senior engineer before you build. You do need to understand enough to make responsible decisions about what you are shipping.

Where is the customer data stored? What can the AI tool see? What happens when a payment fails? Can you roll back a bad change? Who owns the code? What will this cost if usage grows? If the app gives advice, what happens when it is wrong?

I still use AI to explain unfamiliar code and help me investigate problems. The difference is that I now know which questions to ask. I can inspect the plan, challenge a change and decide when something needs a person with deeper expertise. That is ownership. It is not the same thing as knowing everything.

The loop I would use if I started again

I would spend less time comparing tools and more time running the full loop. Pick a problem, build one path, test it with a person, look at what happened and make the next decision from evidence.

A slightly bruised ego is cheaper than six months building the wrong thing. Real users are very good at finding the gap between the product in your head and the product on their phone.

The big shift for me was not that AI suddenly made me technical. It gave me enough agency to stop waiting, start building and learn from contact with the real world. That has been worth far more than the first line of code.