I never planned to become a builder. I don't have a computer science degree. I've never taken a coding bootcamp. For most of my career, the closest I got to technology was approving the budget for people who actually understood it.

I'm in my early 30s and I work in a large bank. I have a Masters in Banking and Finance, and my career path has been about as non-technical as it gets - Financial Crime, then Chief of Staff to a senior executive, then into a Business Management role inside a technology division. I run the only non-technical team in an org of 2,000 engineers spread across the world. My job is budgets, strategy, headcount, vendor management. The people around me write code. I make sure the numbers work.

That's how I ended up in the middle of one of the biggest AI spending decisions in the organisation.

Our CIO and a group of senior engineers came to me with a proposal. They wanted to roll out Cursor licenses across the entire division. If you're not familiar, Cursor is an AI-powered code editor - basically an IDE that can write, edit, and explain code using large language models. The pitch was straightforward: give every engineer access and watch productivity go up.

The price tag was not straightforward. We were talking about 2,000 people at roughly $2,000 per person per year. That's $4 million in annual licensing, landing on my desk for approval.

I pushed back. Hard.

Not because I thought AI was useless - I didn't have a strong opinion either way. I pushed back because the business case was thin. "Productivity gains" is easy to say and genuinely difficult to measure. I'd seen plenty of enterprise software rollouts where the licenses sat unused six months later while the vendor invoice kept arriving. My job was to protect the budget, and $4 million on a tool most of the org hadn't even tried felt reckless.

The engineers were frustrated with me. The CIO was frustrated with me. I was the non-technical person standing between 2,000 engineers and the tool they all wanted. I understood their frustration, but I wasn't going to approve something I didn't understand just because people with more technical knowledge told me to.

So I did the only thing that made sense. I went home that evening and downloaded Cursor myself.

I had no idea what I was doing. I opened it up, stared at the interface, and typed one prompt into the chat: "Build me Pac-Man."

It did.

A fully working Pac-Man game. From a single sentence. The ghosts moved, the dots disappeared, the score went up. I sat there staring at my screen like an idiot. I am a very logical person - I deal in spreadsheets and business cases and risk frameworks - but what I was looking at genuinely felt like magic.

I stayed up late that night. I kept prompting. I built a calculator. A to-do list. A simple dashboard. None of it was good. All of it worked. Every time I described something in plain English, code appeared and ran. No syntax errors to debug, no documentation to read, no Stack Overflow rabbit holes. Just describe what you want and watch it materialise.

I went into work the next morning and approved every single license.

Not because the business case had changed. Because I had changed. I understood, in a way that no slide deck could have shown me, exactly what this tool could do. The engineers weren't exaggerating. If anything, they were underselling it.

That was the moment everything shifted. Not just the budget decision - my entire relationship with technology. For years, the thing that kept me away from coding was that it required massive attention to detail and moved painfully slowly. Fixing syntax issues is my personal nightmare. I'm a fast thinker and a problem solver, but traditional programming punished the exact way my brain works. AI removed both of those barriers overnight.

I started building things after work. Not carefully, not strategically - just building. I wanted to see how far I could push it. Could a person with zero coding experience actually ship real products? Not toy demos, not tutorial projects. Real things that real people could use.

The answer, it turns out, is yes. But with a massive caveat.

Most of what I built early on was trash, and I'm fine with that. I built apps that nobody wanted. I built features that broke immediately. I tried to build too much too fast and ended up with a graveyard of half-finished projects. I wasn't optimising for any single product - I was optimising for the system. Each failure taught me something about how to build faster, test better, scope tighter.

The real shift came when I stopped thinking about individual apps and started thinking about the machine that builds them. I wanted an autonomous AI operating system - something that could research markets, plan products, write code, run tests, and ship. Not a chatbot. Not a wrapper around an API. A genuine operating system for building software.

I've been through multiple iterations of that system. I tried frameworks that got my Claude subscription revoked for Terms of Service violations. Twice. I rebuilt the entire thing natively in the command line. The version I'm running now is by far the best I've had - it manages a portfolio of 15 products, routes work across multiple AI models to manage token spend, and runs research and content pipelines autonomously.

My stack is CLI-only. Claude Code is the backbone. I burn through rate limits constantly, which is why I built a model router that distributes work across Claude, Gemini, Ollama, and Codex. The whole operation runs from the terminal. No drag-and-drop builders, no visual editors, no Lovable or Bolt or v0. Those tools are fine for what they are, but they put a ceiling on what you can build. The command line doesn't.

But here's what I think most builders miss, and it's the thing my finance background actually prepared me for: building software is maybe 30% of running a product business. The other 70% is research, marketing, pricing, positioning, strategy, customer understanding. I have a Masters in Banking and Finance. I've run P&Ls. I've built business cases for eight-figure decisions. That background turns out to be far more useful than knowing how to code, because AI can write the code. It can't tell you whether the product should exist in the first place.

All of this traces back to one evening, one prompt, and a Pac-Man game that probably had a dozen bugs I didn't notice because I was too amazed that it existed at all.

I write this blog because I genuinely believe AI is far more approachable than it seems from the outside. The barrier to entry has collapsed. You don't need a CS degree. You don't need years of tutorials. You don't need permission from anyone. You need curiosity, a tolerance for building things that don't work yet, and the willingness to just open a terminal and type something.

If you're sitting in a non-technical role right now, wondering whether AI tools are actually as powerful as people claim - go home tonight and build Pac-Man. See what happens. It might change your mind about everything, too.

I burn through AI rate limits. Constantly.

Not in a casual "oh I hit the cap once this week" way. I mean I'm on the highest tier of Claude Code and I regularly exhaust my weekly allocation by Wednesday. Sometimes Tuesday. When you're building 15 products, running autonomous workflows, dispatching research agents, and iterating on code all from the terminal - the tokens disappear fast.

Most people hit a rate limit and do one of two things. They wait. Or they switch to a different tool and lose all their context. Both of those are fine if you're building one thing on the side. But I'm not building one thing. I'm running an entire operation from the CLI, and stopping for 6 hours because I've burned through my allocation isn't an option.

So I did what any systems-obsessed person would do. I built a model router.

The naive version of this problem

Here's how most builders handle AI costs. They pick one tool - Claude, GPT, Gemini, whatever - and they use it until they can't. When the rate limit hits, they either sit and wait for the reset, or they manually switch to something else. Maybe they open ChatGPT in a browser tab and copy-paste their context over. Maybe they just go do something else for a few hours.

The problem with this approach is that it treats every task the same. Writing a complex multi-file build that requires deep architectural reasoning? That goes to the same model as formatting a test output or generating a simple config file. That's wasteful. You're burning your most expensive, highest-quality tokens on work that a cheaper model could handle perfectly well.

I realised that the solution wasn't to manage the limit better. It was to stop thinking about individual models entirely and start thinking about pools of capacity that get allocated based on what the work actually needs.

What I actually built

The model router is a Python module that sits between every task in my system and the AI model that executes it. Nothing gets dispatched directly to Claude or Gemini or anything else. Everything goes through the router first.

It works on three principles.

Hierarchy preferences. Every type of task has a ranked list of models, best to worst. Complex builds get routed to Claude Opus first because it has the highest benchmark scores for multi-file reasoning. Research tasks go to Gemini first because it has a million-token context window and it's excellent at web search and long document analysis. Mechanical tasks - running tests, formatting outputs, generating configs - go to Ollama first because it runs locally on my machine and costs literally nothing.

Burn rate tracking. The router knows how far through each billing cycle I am and how much of each pool I've used. If I'm 30% through my Claude week but I've already burned 60% of the allocation, the router knows the burn rate is unsustainable. It starts shifting work down the hierarchy - moving tasks that would normally go to Claude onto Gemini or Ollama instead, preserving the expensive tokens for work that genuinely needs them.

Emergency overrides. Sometimes you need a specific model for a specific task regardless of what the router thinks. The override system lets me force a model choice when the situation calls for it, but it requires explicit approval through a Telegram notification pipeline. No silent bypasses. The friction is deliberate.

Right now the hierarchy table has 94 different task types, each with a ranked preference list across 8 models spanning 4 platforms: Claude (Opus, Sonnet, Haiku), OpenAI (GPT-5.4, Codex-5.3), Gemini 2.5 Pro, and a local Ollama instance running Qwen 2.5 32B. Every task - from "brain loop idle check" to "SDLC complex build" to "research deep dive" - has been classified based on what it actually requires.

How the routing logic plays out

Let me give you a concrete example. My system runs a brain loop - a background process that wakes up every few minutes, checks for work, and dispatches tasks autonomously.

An idle check - "is there anything to do?" - goes to Ollama. Free. No tokens burned.

A morning digest summary that synthesises overnight activity? That needs decent writing quality, so it goes to Sonnet. Good enough, and it preserves Opus for the heavy lifting.

An escalation diagnosis where something has gone wrong and needs root cause analysis? That goes straight to Opus. Deep reasoning. No compromise.

Same system, three different models, three different cost profiles. All automatic. I don't think about it.

Research is another good one. Web scanning and data gathering goes to Gemini because it's genuinely excellent at processing large amounts of information and it has separate quota from Claude. The final analysis and synthesis of that research? That comes back to Opus or Sonnet because the quality of reasoning matters for the output.

The pattern is simple: match the model to the cognitive demand of the task. Don't waste reasoning power on mechanical work. Don't cheap out on work that requires genuine judgment.

The philosophy behind it

I think about this principle constantly: if you're solving the same problem twice, you should be building a system.

The first time I hit the Claude rate limit mid-build, I waited. The second time, I switched to GPT manually. The third time, I started building the router. Because the problem wasn't that I hit the limit once - it was that the limit was going to keep hitting me, every week, for as long as I'm building at this pace.

This is the difference between solving a problem and building infrastructure. Most people optimise their workflow. I'd rather optimise the system that runs the workflow.

Get the machine right and everything scales.

The router is a perfect example. I spent a few days building it, and now it handles thousands of routing decisions without me thinking about it. It's not glamorous work. Nobody's going to see a model router and think "wow, what a cool product." But it's the kind of infrastructure that makes everything else possible.

I have the same philosophy about the entire AI operating system I've built. The products I ship are the visible output. But the machine underneath - the teams, workflows, memory system, scheduler, approval gates, model router - that's what actually compounds. Every improvement to the machine makes every future product cheaper and faster to build.

The broader point

If you're building with AI seriously - not just asking it questions, but actually running your work through it - you're going to hit resource constraints. Rate limits, token costs, context windows, quality trade-offs. These aren't going away. If anything they'll get worse as the models get more capable and more people start pushing them hard.

You can manage those constraints manually every time they come up. Or you can build the system that manages them for you.

I know which one scales.

The model router took me from "I'm stuck, Claude's out of tokens again" to "94 task types automatically distributed across 4 platforms based on real-time burn rates." I haven't manually switched models in months. The router handles it.

That's the systems-first mindset. Don't solve the problem. Solve the category of problem. Then go build something else while the infrastructure handles itself.

I've shipped 15 products. I've killed more than that. 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

Most indie makers I see online are obsessing over one product. They spend six months refining a landing page. They agonise over whether the button should be blue or green. They write 47 tweets about their MRR before they have any.

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 shipped 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.

15 products in the portfolio. 6 deployed and live. 3 iOS apps built. 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.