How I Built This Site in a Week Using Zed, Supabase, Vercel, ChatGPT and Claude

What I wanted wasn’t a blog. It was:

• A personal product hub I could extend like a real SaaS product

A headless CMS I controlled, not rented

• A way to write in markdown and publish instantly


• A system I could automate with AI workflows, not “just a website”

This article breaks down how I built it, what worked, what broke, and what I’d do differently now that the foundations are live.

Building the Foundation

I started with a simple goal: a fast, clean, modern site that I could update without needing to touch the codebase every time I wanted to publish something. Instead of choosing a no-code tool, I decided to build a real product stack that I could evolve over time.

The core decisions:

Next.js for the frontend, because I want long-term flexibility and server components

Supabase as a lightweight headless CMS and database

Vercel for hosting and seamless deployment from GitHub

Zed as my development environment — fast, AI-assisted, and distraction-free

ChatGPT and Claude as pair-programming partners rather than “generators of code snippets”

I didn’t want a blog that lived in markdown files inside GitHub.
I wanted a CMS I could scale, migrate from, and automate later — which is why Supabase became the foundation. It gives me auth, a database, row-level permissions, and APIs without building a backend.

Connecting the Stack Together

The real unlock wasn’t the code — it was the workflow.

1. I built the site locally in Zed, committing into a GitHub repo
2. I linked the repo to Vercel, so every push deploys automatically
3. I mapped my domain (costellocorner.ai) from GoDaddy → Vercel
4. I configured environment variables in Vercel instead of storing anything locally
5. I used Supabase tables to store posts, case studies, prompts, and meta content

Once that integration was working, the website stopped being “a project” and started becoming a system I could publish through — in the same way I once managed multi-product roadmaps.

The logic was simple:
If I can publish with the same ease as posting into Notion, I’ll actually keep the site alive.

Where AI Fit In

AI wasn’t there to “build the site for me.”
It acted as:

• a rubber duck for debugging design decisions


• a writing co-pilot for the CMS schema, content model, and field naming


• a draft accelerator when writing copy or refining wording


• a refactor assistant when I needed to improve folder structure or naming

The real benefit was acceleration, not automation. Instead of searching StackOverflow or reading docs for hours, I asked AI precise questions, got 80% of the answer back, and used judgment for the last 20%.

What I’d Do Differently Next Time

Start with the CMS schema before writing UI — it saves rework

• Add a content approval state earlier (draft, preview, published)


• Build the RSS feed sooner so I could test syndication properly


• Set up image optimisation on day one instead of “later”


• Add observability (logs, performance, errors) right after launch instead of after bugs surfaced

None of these slowed me down, but they made it clear that shipping fast always creates small debts worth paying back in week two, not month six.

What’s Coming Next

• AI-powered writing assistant built into the CMS


• An automated blog publish Agent - #loftygoals

The long-term goal isn’t to run a blog.
It’s to build a living product portfolio — a space that shows how I think, how I work, and how product, writing, and AI are evolving together.

Final Reflection

This wasn’t a personal website project.
It was a proof of concept: that with the right tools, a product leader can build and run a modern software stack without being a full-time engineer.

Not because AI replaces engineering — but because it compresses the cost of learning.

The real shift is this:

You no longer need to choose between “being technical” and “building things.” The only question is whether you’re willing to start.

More to come — and the next version will build itself faster than the last.