Building This Portfolio: A Case Study in AI-Assisted Development
What happened when I used AI tools to design, build, and deploy a portfolio site — and why I deliberately decoupled the live site from the builder.
- Stack
- Lovable, Claude, Vercel, Cloudflare
- Role
- Designer + Builder
- Duration
- 2 weeks
- YEAR
- 2026
Overview
This portfolio itself became a small design-and-build project of its own — not just content to fill in, but a real exercise in working with AI tools across the full pipeline: structuring content, building the site in Lovable, debugging real deployment issues, and making deliberate trade-offs about cost, speed, and control along the way. I'm including this as its own entry because the process surfaced genuine lessons about working with AI tools that I think are worth being transparent about — including what didn't work as smoothly as expected.
The Stack, and Why
- Content & structure: drafted case study content and copy with Claude, working through structural decisions (how to scope a case study fairly when work was done on a large team, how to frame contributions honestly, how to handle client confidentiality).
- Build: Lovable, for AI-assisted UI generation directly from that content.
- Version control & hosting: exported to GitHub, deployed on Vercel — deliberately decoupling the live site from Lovable's own hosting.
- Domain: registered independently through Cloudflare, pointed at Vercel via DNS.
- I chose this stack specifically to avoid being locked into an ongoing subscription once the site was built — Lovable was treated as a build-phase tool, not a permanent home for the site.
What I decided, and why
Deciding what to feature, honestly
Before any UI work started, the harder problem was figuring out what belonged in a case study at all. A large amount of my actual work was collaborative — team-owned pages, features built from existing patterns, or fully co-designed with a colleague. Rather than presenting all of it with equal weight, I worked through each project piece by piece to separate what I could honestly claim as my own decision-making from what was shared, spec'd, or inherited from an existing system — and scoped each case study's 'Key Decisions' section around only the former.
Treating AI generation and manual code editing as two different tools
Early on, I did most of the “polish” work — spacing, copy tweaks, layout nudges — the same way I'd done structural work: prompting Lovable to regenerate sections. This burned through credits far faster than it needed to, for changes that didn't actually require AI generation at all. I eventually shifted polish work to Lovable's built-in text/visual editor, or editing the underlying code directly within the file when a change was simple enough, reserving full AI-prompted generation specifically for structural work. This mirrors a lesson from one of my other projects — AI tools are more efficient as production tools once structure is settled, not as the default tool for every kind of change.
Decoupling the live site from Lovable's hosting from the start
Rather than publishing directly through Lovable (which would tie the site's public URL, custom domain, and long-term availability to an ongoing subscription), I exported the project to GitHub and deployed independently on Vercel. This meant I could use Lovable's Pro tier for exactly as long as active building required, then cancel without losing the finished site.
The messy parts, and what they taught me
Images broke silently on deployment
After exporting to GitHub and deploying to Vercel, every image I'd uploaded through Lovable's editor failed to load — they were referenced through Lovable's own internal asset storage path, which only resolves within Lovable's own hosting. The site looked complete inside Lovable's preview, but broke the moment it ran independently. The fix required identifying the actual failed network requests, tracing them to Lovable's asset system, and having all image references moved into the project's own /public folder with local paths instead. This was a good reminder that 'it works in the builder' and 'it works once deployed elsewhere' are two different claims, especially with any AI website builder that has its own hosting layer.
DNS and domain setup needed more care than expected
Between a free domain offered through Lovable's Pro plan and a separately purchased domain via Cloudflare, I had to understand which parts of a domain (registration/ownership) are separate from which parts (hosting connection) are tied to a specific platform's subscription — an easy thing to get wrong if you assume 'free domain' means 'no future dependency.'
Live edits meant live risk
Because Lovable was connected directly to GitHub, which auto-deployed to Vercel, every edit made in Lovable's editor went live on the actual site almost immediately — with no staging step. I addressed this by moving ongoing work to a separate Git branch, so changes could be reviewed before merging into the branch Vercel treats as production.
What I learned
Working through this taught me that 'AI-assisted' isn't a single mode — it's a set of different tools suited to different stages of work, and using the wrong one for a given task (like burning generation credits on manual polish) is its own kind of inefficiency. It also reinforced something I've tried to be consistent about across this whole portfolio: being honest about what AI actually did versus what I did, including the parts where the AI-generated approach broke in ways I had to debug and fix myself.