I've built 16 products. I've killed more than half of them. And if I'm being honest, most of what I built early on was genuinely bad. Not "rough around the edges" bad. Not "MVP that needs polish" bad. Actually bad. The kind of bad where you look at it a week later and quietly delete the repo.
I'm fine with that.
Here's why: I was never trying to build great apps. I was trying to build a system that builds apps. The individual products were experiments for the machine, not the goal. Every single one - even the ones that were complete rubbish - taught the system something.
The Difference Most People Miss
When I started, I almost fell into the same trap. Pick one product, refine it for six months, obsess over whether the button should be blue or green. Write tweets about MRR before you have any. That's the default path for indie makers and it nearly caught me too.
I went the other direction. I wanted to build an autonomous AI operating system - something that could research a market, plan a product, write the code, test it, and ship it. Not as some hypothetical future state. As the thing I work on every single day.
The products were never the point. The products were how I stress-tested the machine.
Getting My Subscription Revoked. Twice.
Early on I tried building this with a framework called OpenClaw. It was an autonomous agent system that could chain tasks together and operate independently. I pushed it hard. Too hard, apparently - Anthropic revoked my Claude subscription for TOS violations.
So I rebuilt it. Got revoked again.
Most people would take that as a sign to stop. I took it as a sign that I was on the right track but needed to find a way that worked within the rules. I scrapped the external framework entirely and rebuilt the whole ecosystem natively inside Claude Code's CLI. No wrappers, no middleware, no agent frameworks. Just the terminal.
The version I'm running now is by far the best I've had. And it only exists because the first two attempts got killed.
What Trash Products Actually Teach You
Here's what people don't understand about killing products: the product dies, but the knowledge doesn't. Every failed build improved something in the pipeline.
One early product - a simple utility app - was architecturally fine but the research behind it was rubbish. The market was too small, the pricing was wrong, and I didn't validate any of it before building. That failure taught me to front-load research properly. Now my system runs a full market analysis before a single line of code gets written. Foundation documents, competitive scans, pricing models - all before the build starts.
Another product went live with no tests. It worked on my machine and broke immediately in production. That one taught me to bake testing into the build pipeline itself, not treat it as something you bolt on at the end. Now every product that comes through the system gets automated test coverage as part of the build, not after it.
I killed a content tool that was technically solid but had zero distribution strategy. The product worked. Nobody found it. That taught me to wire marketing and launch planning into the system from day one - not as an afterthought you panic about post-launch.
None of those products survived. All of them made the system better. And every product that comes through the system now benefits from those lessons automatically.
"I Build Apps" vs "I Build a System That Builds Apps"
These sound similar. They're completely different mindsets.
If you build apps, you're trading time for products. Every new product is a fresh start. You carry some skills forward, sure, but you're fundamentally doing the work again each time.
If you build a system that builds apps, every product makes the next one faster. The research gets better. The architecture gets more consistent. The testing catches more. The deployment gets smoother. You're compounding.
Right now my system can take a product idea from research through to deployed and live in a single session. Not because any individual piece is magic - but because I've spent months making the pipeline reliable. The model router distributes work across Claude, Gemini, Ollama, and Codex to manage token burn. The orchestration engine handles multi-stage workflows. The quality gates catch problems before they ship.
16 products built. 9 killed. 3 iOS apps among them. And the rate is accelerating, not slowing down. That's what a system gives you.
The Honest Part
Here's where I have to be straight with you: spending this much time on internal tooling is probably not optimal for revenue. I know that. I could have taken my best product, gone all in on marketing, and probably made more money by now than building model routers and orchestration engines that nobody sees.
But I genuinely can't stop. I find the system itself more interesting than any individual product it creates. The challenge of making autonomous AI reliable, of figuring out how to route tasks to the right model at the right cost, of building quality gates that actually catch real problems - that's what gets me up early.
Maybe that's a character flaw. Maybe it's a competitive advantage that just hasn't paid off yet. Probably both.
Why This Matters If You Build Things
If you're a solo builder or an indie maker, here's the thing I'd want you to take from this: stop obsessing over one product. Think about your process.
You don't need to build what I built. You don't need an AI operating system or a model router or any of that. But you should be asking yourself: what am I learning from each build that makes the next one better? And is that learning automatic, or does it depend on me remembering to do it?
The builders who win long term aren't the ones with the best single product. They're the ones with the best machine for producing products. Get the machine right and everything scales.
Most of what I built was trash. The system I built to build them is the best thing I've ever made.