Are you over-engineering your Claude Code projects?

There's a question I ask constantly in product work. Not "what does this need to do?" That's already halfway to a solution. The question I mean is one level further back: "what's the actual outcome we're trying to achieve, what's driving the stated need?"

It's the question that kills features that sound good (or cool...) but aren't necessary, that keeps roadmaps honest, that earns you credibility with engineers who've seen too many over-specified solutions to under-specified problems.

I've been asking it about software for a very long time. As I've got deeper and deeper into the magick of agentic coding, it's taken me embarrassingly long to realise I should also ask it about infrastructure.

Most of the projects I build sit on a fairly standard setup: CloudFlare for hosting, Supabase for the database and auth, GitHub for version control and CI/CD. For hobby projects, my guiding principle on tech choices is simple: ideally free. I've written before about the opinionated project template I've assembled around this stack. It works well. What I didn't do, not once, was go back to each layer and ask: does this project actually need this?

That question, applied to infrastructure rather than features, is what popped into my head the other day. With Claude Code, acting on the answer might be cheap enough that the question is worth asking routinely.

The insight isn't complicated. Different databases are good at different things, and the most capable option is not always the right one. The same logic applies to auth services, hosting environments, LLM APi calls, and everything else in your stack. Right-sizing isn't just a feature roadmap discipline. It's a stack discipline too, and most of us who've stumbled into building things with AI tools never thought about it, because we never had to. We just picked something that worked (or that the AI suggested) and moved on.

What's changed is the cost of revisiting that decision. Before agentic coding, migrating a database or swapping an auth layer was a significant undertaking, enough that you'd think twice before questioning a setup that was merely over-specified rather than broken. That calculus has shifted. If Claude Code can analyse your codebase, confirm your assumption, write the specification, and execute the migration in an evening, the barrier drops considerably. It becomes less "is this worth the effort?" and more "why haven't I questioned this before?"

The cost of not asking is usually invisible, until it isn't. For me, it showed up as a constraint: I wanted to start a new project, and I'd run out of (free) room.

Did I bring a cannon to a butter knife fight?

I run a small site, restaurants.hultberg.org, where I keep a running list of restaurants I want to visit. It's one of the first things I built with Claude that I actually decided to launch and use. Basic CRUD operations, one user (me!), a handful of pages. It's been sitting on Supabase since I built it, because that was the free database hosting with excellent API support and user authentication features that I decided to use as my "default" choice.

Supabase comes with two free databases. One belongs to the restaurant site. The other belongs to Ansible, a Readwise summarisation tool I wrote about a while back. I have a new project forming, something I'm calling QRious Specimens (the name hints at what it does, but that's a story for another post), and it actually needs what Supabase offers: database triggers, advanced queries, row-level security, multiple users, more complex auth. The restaurant site was sitting on the database I wanted to use.

Hey, I'm a cheapskate. Of course I could start paying for Supabase. But what's the sense in paying a monthly fee for a vanity project that makes no money?

So I asked the question. Does restaurants.hultberg.org actually need Supabase?

I put it to Claude Code at around 17:30 one weekday evening, with a request to analyse the codebase and give me a fact based answer. The verdict: no, it doesn't. The site is simple enough that CloudFlare D1, a lightweight SQLite-based database that runs inside CloudFlare's infrastructure, would handle everything comfortably. The one area of real complexity was user authentication. Some pages are public; others show my personal notes and visit records, and there's an Admin section to manage the restaurants, which only I should see.

Getting that boundary right would be the actual challenge in a migration, not the data itself. D1 does not support the kind of authentication feature Supabase brings. But turns out CloudFlare's nearly free tier (I pay $5 per month...) also comes with a service called "Zero Trust" that could do the job. Not the same slick UX as with Supabase perhaps, but more than enough for my single user (me!) website.

That was the kind of answer I was expecting, but it was also the kind of answer I wanted a second opinion on rather than just blindly embark on a rewrite. Claude read the code. It understood the shape of the problem. I decided to trust the analysis.

We worked up a specification for the migration. Then I went for dinner.

At 20:45 I came back, kicked off the implementation, and watched Claude Code work through it in three distinct phases. It gave me a clear list of things I needed to handle manually: backing up the Supabase data, configuring CloudFlare D1, and setting up Google OAuth authentication through CloudFlare Zero Trust. Once I'd done those steps and confirmed them, Claude continued. The implementation itself ran for about 45 minutes. I issued three follow-up prompts related to the Zero Trust configuration, all minor.

By the time I went to bed, the site was running on D1. One available free Supabase database, coming right up. QRious Specimens has a home. Total elapsed time from first question to working migration: one evening, most of which I spent eating dinner.

Here be dragons?

The bare-bones stack I run (CloudFlare, Supabase, GitHub Actions) gives me something that all-in-one platforms can't easily match: freedom. I can right-size each layer independently, swap components when something better (or cheaper) comes along, and keep costs predictable because I understand what each part does. This migration was possible because nothing in my setup was locked together.

But that freedom comes with a cost: no one is checking my work. Technology preferences, security choices, library selections, what goes live and when: those are my calls, and if I get them wrong, I bear the consequence. I try to mitigate this with the review workflows I've described in earlier posts, but I have no illusions about the limits of what I can catch on my own.

That's not a reason to avoid this kind of setup. It is, though, a reason to go in clear-eyed. The question "what does this actually need?" has to include "what level of risk am I comfortable owning?" That's a PM question too, and the answer will be different for everyone.