§ 01 · What we builtA blog built for curious builders, demystifying AI one story at a time
are we there yet? is a field journal of normal people building real things with AI, explaining exactly how it was built with every tool laid out. I designed it, built it, and pushed it live in a few hours of work.
Open LinkedIn right now. You'll see people posting incredible things they've built with AI. What you won't see is how they did it. No tools listed, no process explained, no costs shared. Just "look what I made" and a call to action to DM them. That gap is what this blog exists to close.
There's real tension around AI replacing jobs. I get it. But I think for the people willing to actually learn how to use these tools, there's a small window to accelerate — and the fastest way to learn is to watch someone else do it and copy the parts that work.
I could have started this on Substack or WordPress. But the whole point of the blog is to prove that normal people can build things with AI. So I built my own: a Next.js site that turns Markdown files on my laptop into a static website hosted on Vercel. I write a post, push to GitHub, and it's live.
§ 02 · Build processFrom a LinkedIn rant to a live site in one weekend.
I started where every project should start: figuring out what I actually wanted to say. The idea was born from scrolling LinkedIn and noticing that everyone seemed to be building incredible things with AI but nobody was explaining how. That's a problem. Dropping a quick "send me your output" is fine for engagement, but it skips the part that actually matters for adoption — learning how to do it yourself.
So I sat down and brainstormed what the blog should feel like. The style, the structure, what makes it different from yet another AI blog.
Then I did something that might sound counterintuitive: I took the idea to Gemini first, not Claude. I used Gemini to draft the initial spec sheet — the concept, the sections, the tone. The reason? Context is expensive. I didn't want to burn Claude's context window on the brainstorming phase when I'd need it fresh for the actual build.
I pasted that spec into Claude Design, which generated the front-end design. I liked what it came back with. Claude Design lets you export directly into Claude Code via a shareable link, so I copied that link into my IDE and dropped into plan mode. From there I used Claude Superpowers skills to write a structured implementation plan based on the design.
The first version of the site went up on GitHub Pages — just to see what it looked like on the web. But once I started thinking about the features I'd want down the road — a CMS, a submission form, analytics — I realized this needed to be a Next.js project hosted on Vercel.
After the migration, I went back into plan mode. Claude's "AskUserQuestions" feature walked me through the decisions: how did I want to publish posts, how did I want to manage content, how should readers be able to submit their own stories. Claude recommended KeyStatic for the CMS and Resend for the pitch submission emails. Both turned out to be the right calls.
§ 03 · Problem being solvedA writing home I actually own, with the plumbing already done.
I wanted a place to publish that wasn't rented. Not Substack, not Medium, not someone else's platform where the rules change when the business model does. But I also didn't want to wrestle with SEO tags, social-share images, RSS feeds, and sitemaps every time I hit publish. So I built a template that handles all of that automatically. Every new post inherits the polish for free.
I also wanted two ways in, depending on my mood:
- A visual editor (Keystatic at
/keystatic) when I want forms and drag-drop images. - A terminal command (
npm run new) when I already have a polished draft from a Google Doc or an LLM and just want to paste it in.
§ 04 · What was the hardest partHow the hell am I going to publish content?
Keystatic. Getting the visual admin editor to play nicely with the custom MDX components I'd already designed. Keystatic had its own opinions about how MDX should be serialized, and my components had different opinions. They kept fighting. I'd save a post in the admin, and Keystatic would silently strip my thumbnail path, or break my <Lede> tag, or refuse to recognize a field I'd defined. I spent half a dozen commits in a row just teaching them to share the same MDX format — widening the schema, loosening the components, moving image folders around. None of it was glamorous, but it was the work.
§ 05 · What you learnedThree lessons, on vibe coding and staying human.
One: the brief is 80% of the work."Vibe coding" is actually just writing writing, or dictating very long, very specific English sentences about what I wanted, and watching Claude type them into HTML.
Two: opinions over options. Every time Claude offered three directions I got worse output than when I said "do this, in this exact way." Without the proper supervision, generative tools will head off in the direction they choose. Use auto-accept sparingly when you first start.
Three: the weird stuff is what makes this fun and engaging. Anyone can ship a black-and-white serif site in a an hour with some prompts, its ultimately like pulling a slot machine lever and hoping something cool comes out the other end. The cursive annotations, the margin scribbles, the red question mark logo, those are design choices that I came up with that make the whole thing feel more fun and personal. I think that as utilizing generative coding tools gets easier to use, people will tend to get bored and move on from projects easily. You need to want to build something and think about it deeply in order to appreciate what this technology is actually doing, and try to have some fun along the way.
