Pick a stack your AI can run

I’ve built more than twenty things with AI in the last year. Somewhere around the tenth one I noticed a pattern I didn’t expect.

The thing that decided whether a project was cheap and quick or expensive and annoying was rarely the code. It was decided before I wrote the first prompt. Which stack. Where it would live. How it would get out the door. What it would cost to keep alive if nobody used it. I used to think of that as setup. I now think it’s the part that decides what the rest is allowed to be.

Structure is what makes things possible

Structure decides what you will even attempt. When every new idea means a new repo, a new database, a new login system, a new hosting account and a new bill, you start filtering ideas by how much hassle they are rather than how good they are. Not consciously. You just find yourself not starting things.

When auth, data, hosting and deploys are shared, and every one of them can be driven from the command line, a new idea is a prompt. Set up project twenty-one. The agent creates the repo, the database, the subdomain and the deploy, and I look at the result. Ideas that would have been too expensive, too complicated or too slow to try get tried. Bad structure doesn’t slow you down so much as quietly cap your ambition.

I said not to upgrade the stack. I meant it

A few months ago I wrote about the marathon runners in the supershoes and argued that you should build the engine before you upgrade the stack. Infrastructure doesn’t give you product-market fit. I still believe that.

That post was about one project buying expensive shoes before it had learned to run. This is about building one track that twenty runners get to use. Over-engineering one project is still a mistake. Shared structure across twenty is the opposite of it: the cheapest possible version of each, because the expensive parts were paid for once.

Where mine is right now

Honest inventory. My sites and apps run on Vercel. Data and auth live in Supabase. Domains and email are at Loopia, where they have been for years. Cloudflare has started creeping in for DNS.

None of this was designed. It accumulated, one project at a time, and now every new idea means a new project in three or four dashboards, a new line on a bill, and one more thing to forget about. It’s the kind of setup that makes you hesitate before starting the twenty-first thing.

So I’m looking at moving everything onto Coolify on a single VPS, and pushing more onto Cloudflare. Part of that is cost. The bigger part is that Cloudflare has a command line and an MCP server, so my AI coder can set up DNS for a new project without me clicking through anything. Loopia is built for a person with a browser. I haven’t decided. The point isn’t the particular choice, it’s choosing on purpose instead of by accumulation.

The layers you have to decide on

Whatever you choose, the decisions are the same, and so is the question I ask at every layer: can my AI coder drive it end to end, from the command line or through MCP, without me in a dashboard? I don’t need to learn a stack in depth. I need one the agent can run, and I pick up what I need along the way. That rules out some very good products.

Compute is where the code runs. Vercel does everything for you and charges accordingly. Coolify on a plain VPS from Hetzner or OVH gives you most of the same convenience for a fixed monthly price, if you’re willing to keep the server alive. Or you go all the way onto Cloudflare, with Workers and their containers, so the edge is the host. All three pass the test: Vercel and Cloudflare have command line tools and MCP servers, Coolify has an API, so a new project is a command rather than a form.

Data and auth is where your users and their stuff live. Supabase covers both for me, partly because its command line handles migrations, so a schema change is something the agent does and I review. It’s also where I learned this the hard way. The free plan allows two projects, and twice I killed one to make room for a new idea. Those projects didn’t die because nobody wanted them. They died because of a plan limit, which is exactly the wrong reason, and paying per project would have added up just as fast. So pick one and let the small ideas share it until one of them earns a database of its own.

Domains, DNS and email are the boring layer that bites at the worst moments. Mine are at Loopia, with DNS moving to Cloudflare because the agent can create records there. Keep them in as few places as you can, and write down where.

Payments. If you want to do anything serious you will need to take money, and Stripe is the default. It has a command line and an MCP server too, so products, prices and webhooks are things the agent sets up. If VAT across countries is what stops you from charging, a merchant of record like Paddle or Lemon Squeezy handles it for a bigger cut.

File storage. Amazon S3 might still be the best answer even if nothing else you run is on AWS. Everything speaks it, it’s cheap, and the AWS command line makes buckets and policies a prompt away. Cloudflare R2 speaks the same language with no egress fees, and Supabase Storage and Backblaze B2 are worth knowing.

Five layers, each a decision you make once and live with for every project after. If one of them can only be operated by hand, it sets the pace for all the others.

What about Lovable?

The obvious objection is that Lovable already solved this. Describe the app, get the app, hosted with a database and a login, no layers to think about. For a first project that’s true, and it might be the best way to start that exists right now.

But look at what it is. The same layers, bundled, with one operator inside the box, and the operator is theirs. There’s no command line for your own AI coder to pick up. It can’t add project twenty-one, migrate the database, point a domain or move the whole thing somewhere cheaper. And it’s priced per project, which is backwards for someone who wants to run twenty. You can export the code, but into a structure that was never set up to be operated. An on-ramp, not a home. Optimised for the first project, where this structure is optimised for the twentieth.

A funnel for twenty ideas

I want to test twenty or thirty ideas in parallel without ramping up costs, and let the ideas decide how much money they deserve.

Stage one: the idea lives on a subdomain, on shared hosting and shared structure. It gets an afternoon and a URL. Most things die here, which is fine, because dying here is free.

Stage two: it shows a pulse. Someone who isn’t me uses it. It gets a real domain. A small step, but a good commitment signal precisely because it’s a bit of a one-way door.

Stage three: it makes money. Now it gets its own hosting, its own everything, because there’s finally someone paying the bill. This is the only stage where a project earns real infrastructure.

And a side door. Some ideas work, I use them, and I don’t feel like turning them into a business. Those go open source, the way Atelier did, with the option of a paid hosted version if one ever deserves it.

Someone will say you should kill half-hearted side projects, and they’re right. The structure exists so that killing costs nothing, and so that twenty small bets at once are cheap rather than half-hearted. Those are not the same thing.

Learn the shape of it, not the nitty-gritty

I’m a designer. I don’t write code. I do learn as I go, and after twenty projects I know more than I expected about how deployment works, how to handle API keys properly, what a migration is for, and what breaks when DNS is wrong. What I don’t want is the nitty-gritty. I don’t need to know how a migration works inside. I need to know it has to happen, that the agent can do it, and how to check that it did.

That’s a different kind of knowledge from the one people assume non-technical builders need. It’s the shape of the stack: which layers exist, what each one does, where things live and how they get out the door. Then you pick tools where your AI coder can do the rest, and you learn enough to ask for the right thing.

For your first app you need none of this. Vibe code it, ship it, feel the magic. But if you want to do something serious, you have to get better at this. Not at the level of an engineer running infrastructure at scale. At the level where every layer answers to a command and you know which commands to ask for, which a non-technical person can absolutely reach.

Find yours

None of this is a recipe. Mine is built for one person running many small web ideas and letting them fight for attention. A single deep product needs a different structure. Hardware, another again.

The job is the same though. Find the structure, the pipeline, the way of working that fits your kind of projects. Then keep it boring, so the interesting decisions can go into the ideas.

The cost of starting has collapsed and the cost of finishing hasn’t. Structure is the thing in between. The code isn’t the hard part any more. Picking a stack your AI can run is.