The idea of creating a personal website has been on my mind for a long time.
Not the kind of site you slap together using a template and launch in a hurry, but a place where I can fully showcase my work, experiences, and ideas. The problem is, there’s usually a long period of hesitation between “wanting to do it” and “actually starting”—uncertainty about what it should look like, which technologies to choose, and whether it’s worth the time.
This series documents how I overcame that hesitation and built this website from scratch using Claude Code and a suite of AI tools.
Starting Point: Chatting with AI to Create a Prototype
At first, I only had a few vague ideas: I wanted a portfolio, the ability to write articles, and multilingual support. But these were too broad; diving in headfirst would have led me to realize halfway through that I was heading in the wrong direction.
I used the brainstorming skill in Claude Code to refine my requirements. The way this tool works is quite interesting—it doesn’t dump a bunch of questions on you all at once, but asks just one question at a time, and tries to use multiple-choice options whenever possible.
For example, it might ask:
What is the main purpose of this website? (A) Pure portfolio (B) Blog-focused (C) Both
How many languages do you need to support? (A) Chinese only (B) Chinese and English (C) Three or more languages
What level of admin access do you need? (A) Direct code editing (B) Simple CMS (C) Full admin panel
Back and forth like this, after about a dozen questions, your originally vague idea turns into a concrete list of requirements. The benefit of this process is that it forces you to think through every aspect before you start working. Often, you think you’ve got it figured out, but when asked specific questions, you realize you haven’t at all.
From Requirements to Design Specifications
Once the brainstorming session is over, the next step isn’t to start writing code right away, but to produce a design document (spec).
This spec is stored in the project’s `docs/superpowers/specs/` directory and covers:
Technology stack: Which framework and database to use, and why
Data Model: Which models are used and how they relate to each other
Page Planning: Which pages are in the frontend, and what features are in the backend
Multilingual Support: How translations are stored, how to switch between them, and which language is the primary one
The spec doesn’t need to be as thick as a thesis, but every decision must be justified. For example, why choose Next.js App Router over Pages Router, or why use Prisma instead of Drizzle—these points will be constantly referenced during the implementation phase.
Once the spec is complete, I’ll review it to ensure there are no omissions or misunderstandings. This step is crucial because once the spec is finalized, the subsequent implementation plan will follow it exactly.
From Design to Implementation Plan
Once the spec is confirmed, I use the `plan` skill to break it down into an actionable implementation plan.
The plan is saved in the `docs/superpowers/plans/` directory, formatted as a list of tasks with clear completion criteria. Each task is very specific: which files to modify, what tests to write, and what to verify upon completion.
For example, the single item “Implement multilingual support” would be broken down into:
Set up the i18n configuration file (supporting zh-TW, en, ja)
Create the Prisma model for the translation group
Implement locale-switching middleware
Integrate translated content into front-end pages
Adding a language-switching UI to the backend
Each step is independently testable—you can run and verify that it works after completing each step, rather than waiting until everything is finished only to discover that a component isn’t connecting properly.
What does this process solve?
Looking back, the greatest value of the “Concept → Spec → Plan” path is that it allows you to walk through the entire project before writing a single line of code.
In the past, my habit with side projects was to start coding as soon as an idea struck. If I realized the architecture was wrong halfway through, I’d scrap it and start over. After repeating this a few times, I’d lose motivation and give up. This time was different: because I had the spec and plan, I simply followed the checklist step by step once I started, rarely having to go back and change the overall direction.
Of course, no plan can perfectly predict every scenario, and adjustments are still needed during implementation. But with this foundation in place, the changes required are usually minor—I never find myself in a situation where I realize halfway through that the entire direction was wrong.
In the next post, I’ll cover design and visual prototyping—how to use tools like Cinematic-UI to turn a list of feature requirements into a tangible, visual interface.