~/work/ai-website-experiments
AI website experiments
Practical experiments with AI-assisted website building, from prompt to production. Not hype; just what works.
- started
- 2026.01.01
- ended
- — present
- role
- Builder, deployer, observer
- stack
- ClaudeGitHubVercelNext.jsTailwind
What it is
An ongoing series of small, real websites built with AI assistance and deployed end-to-end. The point isn’t to prove that AI can write code — that’s settled. The point is to figure out what the day-to-day workflow actually looks like when you take it seriously as a production toolchain.
So far this has meant: working with Claude to plan, generate, and debug code; pushing to GitHub; deploying on Vercel; and watching what breaks.
Why it exists
I started doing this because I wanted to ship something. The gap between “I have an idea” and “there is a live website” used to take me weeks. With the right workflow it now takes hours.
That’s a meaningful change, and I don’t think the implications are well-understood yet. Most of the public conversation is split between people who oversell it and people who dismiss it. The interesting work is in between: what does it actually do well, what does it do badly, and what does the production workflow look like when you trust it for real?
This project page is the index for those notes.
Sites built so far
- darksideautokit.com — [ADD ONE LINE OF CONTEXT: what the site is, what was built, what the goal was.]
- [ADD EVENTS BUSINESS WEBSITE] — [ADD ONE LINE OF CONTEXT.]
- This site. A working archive built in Next.js + Vercel with AI assistance throughout. The most deliberate of the three.
Each one taught me something different.
How it works
The workflow I’ve settled on (for now):
- Write the brief first, in plain English. A document that says what the site is for, who it’s for, what it must do, what it must not do, and what it should feel like. This is the most important step and the easiest one to skip.
- Plan the architecture before writing code. What pages? What content types? What stack? Decide once. Decide on paper.
- Generate in small pieces, not all at once. Page by page, component by component. Easier to review, easier to fix, easier to learn from.
- Deploy early and often. Push to GitHub the first day. Get a live URL the first day. Iterate against the real site, not against an idea of a site.
- Read everything that gets generated. This is non-negotiable. Code you don’t understand is code you can’t maintain.
What I’ve learned (so far)
[ADD A PARAGRAPH OF HONEST REFLECTION — what’s worked, what hasn’t, what surprised you.]
What’s next
[ADD CURRENT FOCUS — e.g. “Working on this site as the most ambitious version of the workflow, then a follow-on essay about what the day-to-day actually looks like.”]