HomeSide projectsProduct Builder's Field Test with AI Tools
Side project

Product Builder's Field Test with AI Tools

LovableClaude DesignClaude CodeClaude Co-workCursor AgentGitHubDNS & Domain SetupVercel Deploy
April 2026
The setup

This is the story of how I used AI tools, one domain registrar, and a live runtime debugging session to build the site you're reading this on, guptapallavi.com.

Lovable, and the slow ceiling

Five months ago I started building this in Lovable. The visual output was decent for a no-code tool, but I hit limits fast:

  • Every content update was a chore. Brainstorm a case study inside Claude Code, generate a clean .md, copy it into Lovable, ask Lovable to wire the page up. A single sentence change meant walking Lovable through it again.
  • Lovable's default look didn't hit what I wanted, and I didn't have a design system of my own.
  • The workflow worked. It was slow.

Something had to give.

The day Claude Design dropped

Anthropic shipped Claude Design on April 17, 2026. By that weekend I was experimenting with it. Within a few hours I noticed the quota was burning fast: if I let it generate the whole Next.js project, I'd be out of credits before I had anything I actually liked.

So I narrowed its job:

  • Forget file structure, frameworks, deployments. Just give me HTML. Just design the front end.
  • Fed it screenshots of sites whose typography, color palettes, and layout density I admired.
  • Worked the design until the visual was right. Plain HTML. No framework noise. Quota intact.

I asked Claude Design to generate 4 different layouts. The current portfolio mixes the best of two.

Constraining the tool to its highest-value job is the line I keep coming back to.

The handoff

Once the visual was where I wanted it, I asked Claude Design for one more thing: take this design and generate a clean Next.js project structure. Why Next.js? I'd already worked out the hosting story: Vercel deploys Next.js best, and Vercel was where this site was going to live.

I handed the generated project to Claude Code. The pace changed entirely:

  • Localhost on port 3000, hot reload, full project context loaded.
  • Every case study, every tag, every layout tweak, driven from the CLI.
  • The full content of my product work already lived in Claude Code, so writing the case studies was one conversation away, not a copy-paste shuttle.
  • GitHub was already wired into the CLI. Push to main, Vercel auto-deploys, done.

The build pipeline became invisible, which is how a build pipeline should feel when you're focused on the product.

The model bench

Claude Code drove the build, but I ran it from inside Cursor's terminal: file tree, markdown previews, and live changes side by side. Cursor also gave me access to other models, which meant I could send the right task to the right model.

  • OpenAI's image generation for the apple-and-Claude-Code image in The Apple and Claude Code.
  • Gemini's image generation for some of the illustrative images on the site.
  • Claude's Sonnet and Opus for everything else: code, copy, decisions.

Outside Cursor, I used Whisper Flow for voice-to-text input during long Claude Code conversations. Talking through a problem turned out to be faster than typing it.

What you're seeing isn't the work of one tool. It's an amalgamation of different LLMs, each doing what it does best, stitched together with judgment about which to use when.

The DNS rabbit hole

The next part I had never done before. I wanted my own domain, went to GoDaddy, bought guptapallavi.com. It's my name, why not.

Then I hit DNS. A records vs CNAME records. www vs apex. Multiple tabs open: Vercel's setup screen, GoDaddy's records panel, help docs from both, security settings I didn't recognize. I was three help docs deep when I remembered Claude Co-work could see the tabs I had open in Chrome. So I let it.

What Co-work gave me:

  • Runtime commentary as I switched between Vercel and GoDaddy.
  • Which row to copy where.
  • Why the apex needed an A record but www needed a CNAME.
  • What to do when propagation didn't kick in immediately.

I went from “I don't know what a CNAME is” to my domain serving live, in one session.

The way I work

This site is the artifact of how I work as a product builder:

  • Pick the right tool for each layer.
  • Stay aware of the constraints (quota, framework fit, deployment target).
  • Don't get attached to one workflow when another is doing the job better.
  • When the work hits something I've never done before, treat the unknown as the part to learn, not the part to avoid.

Curiosity has always been my superpower. Building this site let me lean into it: trying new tools as they shipped, finding my way through things I'd never set up, learning by doing.

A portfolio that talks about being a product builder is one thing. A portfolio that has been built like one is another.

Result

Live at guptapallavi.com. Auto-deploys on every push to main. Every case study, every tag, every animation, every word, shipped by me.