Case 2: How I built this site
I wanted to turn the site's own construction into a case. For a "built with AI" section, nothing feels more honest than the meta-project: the house showing itself from the inside. Below, the tools that came into play, the path I walked, and what I'd do differently if I were starting today.
Tools, and what each one was for
You can't outsource everything to one tool. Each piece of the stack solved a specific part of the problem, and understanding when to switch tools was part of the work.
I opened a dedicated Claude project before writing a single line of code. That's where I scoped objectives, section structure, and tone. Throughout the build, I came back every time I needed to make an architecture decision, write copy, or debug something Lovable couldn't solve on its own.
Took the idea from paper to screen in minutes. It received the detailed prompt that Claude helped me structure and returned a first navigable version. Great for fast layout iteration, but the fine detail and ongoing maintenance asked for a different place.
The bridge between what was a Lovable project and something truly mine. I exported the code here for history, experiment branches, and most importantly, autonomy: from GitHub on, Lovable became optional.
Where the exported code became something truly mine. Typography, spacing, micro-interactions, logo, copy — everything passed through here. I started shy and ended up navigating files with confidence.
The glue that holds it all together. Git, npm, build scripts, deploy. The least sexy and most essential part — almost no AI project escapes this. I used to be afraid of the terminal. I lost that fear on this project.
Hosting, DNS, SSL, and domain in one place, free of charge. Pages handles continuous deploys straight from GitHub: every git push becomes a new version live in 1 to 3 minutes.
From ambition to deploy
Five stages, in a loop. AI did a lot, but the rhythm came from knowing which tool to use at which moment — and when to step two squares back.
I started in Claude, in a dedicated project, telling it about my ambition: I want a portfolio that shows my non-linear background, hosts a blog about AI applied to growth, and a section to document things I've built with AI myself. Claude didn't answer right away — it opened a series of questions to detail objectives, audience, and scope. That pre-production work saved enormous rework later.
Out of that came a long, detailed prompt, which I ran in Lovable. The first version came out beautiful, but the architecture was incomplete — some routes missing, the PT/EN translation system half-broken, content in strange places. I exported to GitHub, and that's where it really became mine.
From there, the loop was always the same: asked Claude for tweaks, which returned instructions for me to paste into the terminal and refine in VSCode. I refined the logo, wrote each section's copy (in different chats, always inside the same project), and published essays one by one. Each new essay is a git push that Cloudflare detects and ships.
Good vibe coding isn't "AI does everything on its own." It's directing AI with clarity, taste, and judgment. Accept the first output and you ship a generic site. Iterate with criteria and you ship something good. That's the real skill.
What I'd do differently
I learned a lot along the way, but learning wasn't the deliverable — it was a byproduct. If I were doing it over today, with what I know now, I'd change four things.
I'd start with references, not a prompt
I'd look for open-source portfolio sites before prompting from scratch. Structuring and fixing the architecture that came out of Lovable took many interactions — and that's not where I create the most value. I learned in the process, but it would have been more productive to start from something already structured and spend time only on the customization that matters: identity, copy, cases.
I'd go straight to Claude Code, no fear of the terminal
I was afraid of the terminal before starting. I lost that fear on this project — and it became an ally. Next time, I'd skip Lovable and go straight to Claude Code: more control, more power, and the learning curve is already the same as "after Lovable," so there's little reason to go through the intermediate step.
I'd set up a CLAUDE.md from day one
To avoid giving the same instructions over and over, the right move is to keep them in a context file Claude reads every time. Things like "avoid em dashes," "avoid negatives that read as AI," "how I commit," "what's the current state of the code." Every new chat started from zero on these conventions, and that was pure rework.
I'd accept that project ≠ full memory
Even inside the same project, Claude doesn't retain everything across chats. It forgets how you're committing, what the latest version of the code is, what decision you made three conversations ago. Knowing this changes how you start each chat: giving explicit context becomes the first step, not improvisation.