The Trap of Best Practices in an AI Build

Search Reddit for the best tech stack, and you will find debates about scalability, edge caching, and bundle sizes. Ask X, and you will be told to use the thing that launched last Tuesday because it is 4% faster.

Both are wrong when you are an operator building with AI.

When you are the sole founder and your team is a collection of language models — Claude, ChatGPT, Gemini — you do not optimise for performance. You optimise for fluency.

Before I opened VS Code, I had to freeze the tech stack for O9X. I did not pick the tools that were best. I picked the tools my AI staff could use without making errors.

The Language: TypeScript as Chain of Command

I had a key choice: Python or TypeScript.

I chose TypeScript. This was not about the code. It was about oversight.

When you build with AI, you are not the coder. You are the code reviewer. The AI writes 90% of the syntax. But the AI also lies. It imports libraries that do not exist. It writes logic that looks right but fails silently.

If I had chosen Python, I would have been blind — I do not have the expertise to spot subtle Python errors. With TypeScript, I kept that ability. I could look at the AI’s output and say: that type definition is wrong.

Never let the AI build in a language you cannot read. You cannot supervise a worker whose output you cannot evaluate.

The Frontend: Fluency Over Function

I looked at four options.

Astro is excellent for speed but built for static content. O9X is a dynamic operational dashboard. Nuxt I had heard good things about, but did not know it well enough to debug when the AI made mistakes. Svelte developers love it, but my tests showed the language models were fluent in Svelte but not native — they made syntax errors and forgot patterns.

React JS is the standard, but it requires immense scaffolding. Two days of setup before a single button is built. I did not have time for boilerplate.

I chose Next.js for two reasons. First, I know it — my company website runs on it, so I can spot a bad hook. Second, the AI knows it best. Next.js is the English of the coding world. Language models have ingested more Next.js documentation and GitHub repositories than any other framework. When you ask for a complex server action, the AI does not guess. It executes.

In an AI-led build, popularity is a feature. The more code that exists online, the more capable your AI co-coder is.

The Backend Hosting: Latency vs. Complexity

The database, PocketBase, needed a home. It could not stay on localhost, but AWS was out. I am not a DevOps engineer. I refused to burn 20 hours configuring a VPC.

I evaluated three options. Pockethost.io promised one-click setup. I tried it. Queries were slow, and I knew my staff would treat slow as broken. DigitalOcean is the standard advice — spin up a Droplet — but managing Linux updates, firewalls, and backups is not building the product. It is overhead. And it is expensive for a prototype.

PikaPods runs open-source apps on their infrastructure, charging only for the CPU and RAM you use. The catch: their servers are in the EU. My users are in India.

I accepted the latency. PikaPods gave me managed hosting with raw resource control. I could cap my spend and adjust RAM with a slider. I chose to accept the EU server lag in order to buy development speed. That latency is a problem for production, not for the prototype stage.

The Frontend Hosting: Escaping the Vercel Tax

The default host for Next.js is Vercel. It is fast and the industry standard. It is also a financial trap for a bootstrapped operator.

O9X will eventually have heavy usage. Vercel’s pricing scales aggressively with that usage. I needed a ceiling I could control.

I considered packing the frontend and PocketBase into a single Docker image on DigitalOcean. The verdict: too much friction. Days managing containers instead of building features.

I chose Cloudflare Workers and Pages. The free tier is generous. If we scale, the Pro tier is $5 a month — predictable, unlike Vercel. The trade-off: Cloudflare uses an Edge runtime, not Node.js. This had to be explicitly told to the AI. If the AI does not know we are deploying to Cloudflare, it writes Node-only code that crashes on the Edge.

I chose Cloudflare to cap my downside risk. I accepted the stricter runtime constraints so I never wake up to a surprise invoice.

The Frozen Stack

The O9X stack is locked for the first prototype. TypeScript for oversight. Next.js for maximum AI fluency. PocketBase for simplicity. Cloudflare Workers and Pages for cost control. PikaPods for managed backend hosting.

Is this the best stack in the world? Probably not. Is it the stack that guarantees I can actually ship? Yes.

Once the decisions were frozen, it was time to start building.