I rebuilt my website last week.

Start to finish in about 40 minutes.

I didn’t create a PRD, feature specs or really have a plan.

I talked at it for 10 minutes and let it go.

And that is the exact opposite of how I build everything else.

Now here’s the thing…

I’ve built websites and apps for clients a dozen different ways over the last few months.

Whatever the YouTubers were pushing that month. Whatever “best practices” Claude or Codex handed me when I asked for them.

What I’ve landed on is that there isn’t one right way to build with AI.

There’s a small way and a big way.

The small way

My site has a handful of pages and barely any database entries.

There’s nothing clever happening under the hood.

So I didn’t treat it like it was clever.

I did the UI first.

Lined up every page I wanted, then got Codex to build them out.

At the same time it pulled in all of my old newsletters. The scraping is genuinely good now with Astra.

Then I just spoke to it for 10 minutes. Everything I wanted. The design style, the type, the colours. One screenshot of a layout I liked.

Ten minutes later it was 90% there.

Another 10 minutes to add auto-posting for the newsletters.

Another 15 going over the copy page by page, because it wasn’t quite right.

I’m now guaranteeing clients that we can save them 40 hours per week (approx $100k per year) within 6 months, or I work for free until I do.

And my fee is a fraction of that cost.

​Check it out here.​

The big way

Now try that on a real app…

I have multiple times.

It works brilliantly for about a week.

Then the codebase gets big enough that the AI can’t hold it anymore.

It gets lost. It makes mistakes.

That’s not an AI problem. That’s me handing it a mess and expecting it to navigate.

So on anything real, the process looks nothing like the website:

1. A PRD first. What are we actually building here, and for who.

2. The context it needs. Legacy AI workflows, the databases, any extra design context, etc.

3. A feature spec before any coding starts.

4. Then build it, verify it, commit it. And let CodeRabbit check the code before anything merges.

And the feature spec isn’t a paragraph of vibes. It clearly maps out:

That last part matters more than people think.

Telling it what’s out of scope stops half the mess before it starts.

It’s slower. You think a lot more. You’re using your own brain again.

But it still works when the codebase gets big.

And the fast way doesn’t.

So…

Match the method to the size of the thing.

I’m putting together a video on the big way… the full step-by-step for large codebases. Feature specs, approval gates, and CodeRabbit doing the reviews so I’m not the bottleneck.

And I need example use cases to build.

So if you’ve got a piece of custom software you’ve been wanting built… reply and tell me what it is.

If I pick yours for the video, I build it for FREE. You get the GitHub repo and it’s yours to do whatever you want with.

That’s thousands of dollars of build time, and all it costs you is a reply.

Talk soon,

Mitch