Why I Keep Building Apps When the Results Are Still Small

I have eight apps live. I am still trying to make this into a real business.

Some people only care about money. A friend asked me, “How much money have you made so far?” It is a fair question. About $50/month is a small answer.

The easy version of this story is that AI makes it possible to build a lot, so I build a lot. That is true, but it is not the reason I keep going when something does not work.

I like building and creating things. I also like the part that comes after a miss: learning what was wrong, changing it, then trying again. That cycle is the actual work.

This is the real Git output from the repo that runs the portfolio. It is activity, not proof that I made the right calls. I keep it because it shows how much of the work is repetition, correction, and trying again.

$ git rev-list --count HEAD
5516

$ git rev-list --count --since='2026-07-24 23:59:59' HEAD
914

$ git log --reverse --format='%ad %s' --date=short | head -1
2026-03-20 Add centralized marketing platform design spec and research

What I am actually getting better at

I want to be financially independent. I also think the opportunity to build useful apps with AI is obvious. More than that, I have always liked building and creating things. It feels like something internal that I need to fulfill.

I do not want to confuse the opportunity with proof that I have already figured it out. I have not. The portfolio has one Focus app, three Maintain apps, and four Incubate apps. That gives me a way to keep an app alive, learn from it, and turn the dial down when the signal is weak.

The work changes quickly. Since the previous devlog, the repository has recorded 914 commits. On August 8, the system gained growth playbooks for all eight apps, an App Store subtitle and keyword changes, and three staged releases. The following day, a new guard required receipts before the system could mark a growth outcome as real.

That is the work I want to get better at. I want to know what to optimize for, what to avoid, and how to carry a lesson from one app into the next instead of starting from zero every time.

Building > failing > learning > building > failing > learning. I believe that process helps me become better. In five years, I will be so much better.

What broke: the system was learning from noise

I do not just need to learn from my own mistakes. I need to make sure the machine is not learning the wrong lesson faster than I can catch it. This is the version that changed how I think about my own role.

On July 30, I had to disarm an automated kill-or-scale actuator because it was deciding on noise. Its score had no engagement data behind it. Some view counts had been copied forward with new timestamps for 15 days, which made stale numbers look fresh. On the only app with enough live data, a median post had roughly the same chance of being called a KILL as a SCALE. It was a coin flip dressed up as a measurement.

I turned the actuator off. It still logs what it would have done, but it cannot act. Two days later, the system required four clean weeks before it could call an App Store change a verdict. This is why I keep the uncomfortable human part. I need to notice when a process has become confident without becoming right.

I also made the more ordinary founder mistake: treating building as enough. Sales and marketing are the bottleneck. I knew that. I was still repeating a mistake I had seen other founders make.

That is embarrassing because it is not a new lesson. I have seen other indie developers make the same mistake. But that is part of the process. If I need to fail many times to get one thing right, so be it. I would rather accelerate the feedback than protect myself from looking wrong.

AI makes the loop faster. It does not remove me from it.

I am using AI to research, write drafts, prepare store changes, run checks, and keep a lot of small processes moving. It lets me try more things. It also creates a new problem: a system can produce activity much faster than I can judge it.

So I am still in the loop. I am trying to remove myself from the work that does not need my judgment, while getting better at the work that does.

I need enough space to look at the actual result and decide what should happen next.

This is why I do not want to fully kill an app just because it is not working today. An app can move from Focus to Maintain. It can sit in Incubate longer. It can keep teaching me something without taking over the whole week. Day One exists because I built the apps before it. The earlier apps were not wasted just because they did not become the winner.

The thing I am trying to compound

I do not know which app will be the one that changes the business. It might not work for me, but it is part of the game and I am okay with that.

What I can control is whether every attempt leaves me with better judgment: how to spot a weak experiment, what customers actually care about, when a metric is too small to mean anything, and where I still need to do the uncomfortable human work myself.

Building the app is getting easier. Learning how to sell it, market it, and operate it is the harder part now. I am collecting those lessons while I build the machine that helps me manage them.

If you are building your own project, copy this into the place where you make decisions:

1. What changed?
2. What did I expect to happen?
3. What evidence would make me keep, change, or stop it?
4. What should the next attempt inherit from this one?

Write the answer down before the next attempt. Otherwise, you are just busy.

I write about building and running iOS apps with AI agents. For the system that manages the work around the apps, read how I built it.