I've been putting off building a personal website for years. I used to run on WordPress, but maintaining it felt like a second job. Plugins broke, themes needed updates, and honestly, I just wanted a clean place to put my work without the overhead.
So when I finally sat down to do this over the weekend, I opened Claude and said: "I'm thinking of using something like Lovable to code it but I'm open to ideas, plus also hosting it."
What followed was about three hours of actual work spread across a Sunday, with most of that time spent on DNS setup (always the DNS setup) and deciding what I actually wanted the site to do. The building part was surprisingly fast.
What I Actually Needed (Spoiler: Not Much)
The brief was straightforward: a place that holds both my professional consulting work and my personal writing. Cup & Weekend lives on Substack and I want to keep it there, but I needed somewhere to host the meta-layer. The stuff about building Cup & Weekend itself. Growth experiments, what's working, what isn't. The kind of notes that don't belong in a parenting newsletter but are useful for people trying to do similar things.
I also wanted to keep costs minimal. Framer looked nice but at $15/month it felt like overkill for what's essentially five HTML pages. Claude suggested building a static site and hosting it for free on Vercel. Total cost: $12/year for the domain.
The Back and Forth (Or: How Websites Are Actually Made)
Building this was built off a series of conversations. I'd ask for something, Claude would build it, I'd look at it and say "actually, can we..." and we'd iterate. The design went through a few versions before I was happy with it.
At one point I asked: "Mum and Consultant? Is that nice?" Claude offered alternatives like "Growth Leader & Writer" but I liked the honesty of "Growth Leader & Mum." It signals exactly what I'm doing, which is holding both things at once.
The site structure took a few tries too. I knew I wanted separate spaces for consulting work and writing, but figuring out where "Building Notes" (this thing you're reading now) should live took some thinking. Claude suggested three options. We went with Option 3: keep Cup & Weekend essays on Substack, host the meta-content here on yininglim.com.
The Technical Bits (In Which DNS Tries to Ruin My Sunday)
I know enough HTML and CSS to be dangerous, which is to say I can read it but I'm not writing it from scratch. Claude handled all of that. It built five pages (Home, Work, Writing, Projects, Contact), a shared stylesheet, a blog post template, and a README with instructions for how to add new posts.
Then came deployment. I already had a domain, and Claude walked me through connecting it to Vercel via GitHub. This part involved actual troubleshooting. The first DNS setup didn't work. We had to delete conflicting A records. There was an SSL error that resolved itself after a few minutes. Very normal website stuff, just compressed into an afternoon instead of spread across weeks of Stack Overflow searches.
I also set up a subdomain (kaboomlabs.yininglim.com) for games I've been building with my kids using Lovable. That required one more DNS record and about ten minutes. The whole thing is modular, which means I can add more subdomains later if I want.
What This Actually Looks Like (Spoiler: Not Like the Ads)
People talk about AI tools like they're either magic or useless, but the reality is somewhere in between. Claude can't read my mind (surprise!) I had to know what I wanted, or at least be willing to say "not that" enough times until we got there. But it handled all the parts I didn't want to think about. File structure, CSS variables, mobile responsiveness, GA4 tracking code in the right place.
The collaboration was: I make decisions, Claude executes them and suggests things I hadn't thought of. When I said I wanted to add analytics, it asked for my tracking code and added it to every page. When I uploaded a messy HTML file exported from a word processor (oops sorry I was lazy!), it cleaned it up (without complaints!) and reformatted it properly. When I said I could't recall the differences between subdomain vs subdirectory for hosting multiple projects, it explained the tradeoffs and let me choose.
On Reversible Decisions and Not Panicking
One thing that made this easier was knowing that almost every decision was reversible. Jeff Bezos talks about one-way doors versus two-way doors. One-way doors are permanent decisions that are hard to undo. Two-way doors are decisions you can walk back through if they don't work out.
This entire project was two-way doors. Don't like the design? Change the CSS. Want to reorganise the pages? Rename some files. Hate the whole thing? Start over. It's just HTML files on GitHub. The stakes are low, which meant I could experiment without overthinking it.
That's different from a lot of technical decisions, which feel high-stakes because you don't know if you can undo them later. But static sites are forgiving. You're not locked into a platform or a framework. You're just editing text files, and that freedom to iterate is what made this doable.
Why I Didn't Use the Fancy Robot (And You Probably Shouldn't Either)
There's a lot of talk right now about OpenClaw and agentic coding tools that can build entire applications for you. And those are genuinely impressive. But they're also inaccessible to quite a lot of people, and honestly, a bit dangerous if you don't know what you're doing.
If you don't understand the code being generated, you can't debug it when something breaks. You can't modify it to fit your needs. You're essentially running software you don't understand, which is fine until it isn't.
What I did instead was start with something simple that I could actually comprehend. Five HTML pages. One stylesheet. A folder for blog posts. I can read every line of code on this site and understand what it does. That means when I want to change something, I know where to look. When something breaks, I can fix it.
The goal wasn't to build the most technically sophisticated thing, it's not a show-off session, and I quite like to go the minimalist track. The point here was to build something that solved my actual problem—having a place to put my work—in a way I could maintain myself. That's the difference between using AI as a tool and using AI as a black box.
Making It Doable (Not Easy, Just Possible)
There were moments of frustration. DNS records didn't work the first time. I had to Google what a CNAME was (again). The SSL certificate threw an error and I just had to wait for it to resolve itself.
But those were small problems with clear solutions, not the kind of overwhelming complexity that makes you give up. And that's the point. You don't need to understand everything. You just need to understand enough to know what you're looking at and where to ask for help.
What made this doable wasn't that it was easy. It's that every piece of it was legible. I could see what was happening at each step. Claude could troubleshoot and explain things when I asked. The files were simple enough that I could edit them myself. The deployment was automated but not invisible.
I'm making it doable by choosing tools I can understand and problems I can actually solve. That's what building in the margins looks like for me right now.
So Go Build Something
If you've been putting off building a personal website because it feels like too much work or you're not technical enough, this is your sign. You don't need to be a developer. You just need to be willing to have a conversation with a tool that can do the technical parts while you focus on what you actually want to say.
I used to run on WordPress and it was fine, but maintaining it took time I didn't have. Now I have a site that does exactly what I need, costs almost nothing, and I can update it myself by editing a text file and uploading it to GitHub.
This whole site, from first message to live deployment, took one Sunday afternoon. Most of that was me deciding what I wanted. The building part was fast. And now I have a place to document what I'm learning as I go.
Starting with this.