How I Started building My Own Product with Claude Code

The origin story (a.k.a. "Why is this PM writing code?")

Quick confession: I have a tech degree. I was also, by my own honest admission, not great at coding and not particularly interested in it. So naturally I went into product management, where my job became thinking up brilliant ideas and then politely waiting for very busy developers to maybe, possibly, eventually build them.

When I joined ConveGenius as a product intern, I noticed a pattern. I'd talk to devs, they'd nod, and then the backlog would swallow my idea whole, never to be seen again. Not their fault, they were drowning. But I kept thinking: what if I just… built it myself?

Spoiler: I did. And now I'm going to tell you exactly how, so you can too.

The FMB chapter : where the survey builder was born

If you've worked on FMB, you know the drill. Creating dumpsheets and surveys was a circus errors everywhere, endless back-and-forth between the state team (hi, that was me) and the tech team. Tickets, follow-ups, "can you check this once?" on loop.

The tech team did eventually whip up a survey builder, but let's just say it was held together with template tape and prayers. Not their fault either they were under deadline pressure. But it wasn't solving the problem.

So I rolled up my sleeves and built one. From scratch. As a person who, may I remind you, was not great at coding.

My AI toolkit (the slightly chaotic evolution)

Here's the embarrassing-but-real progression of tools I used:

1. Lovable : Good for prototype, Useless for scalable real Products.

2. GitHub Copilot Pro : free via student ID, came with a Claude model. Started here.

3. Codex via ChatGPT Pro : picked this up through the ConveGenius team plan.

4. Claude Code : the final boss. This is the one that's real deal.

I used all of them, step by step, layered on top of each other. Each one pulled its weight at different stages. By the end, I'd shipped a real, working survey builder with genuine UX touches, fewer clicks, less typing, the kind of polish that comes from being a product person who finally has the keys to the car.

And here's the magic: I'd be mid-build, get a new idea for a tiny enhancement, and just… do it. No JIRA ticket. No sprint planning. No "let's revisit in Q3." Just me, the AI, and a slightly excessive amount of coffee.

My free-tier startup stack (you're welcome)

For my fellow broke-but-ambitious builders, here's what I use, and how much it costs me: nothing.

• Vercel → frontend deployment. Free, gives you a domain, and you even get one cron job (automation) per project. Just one. Don't be greedy. Pair it with Next.js, they're basically married.

• Render → backend deployment. Also free, also gives you a domain. Tiny heads-up: the free tier sleeps after about 15 minutes of inactivity, so the first request after a nap takes a few seconds to wake up. Fine for prototypes, annoying for demos. Hit your backend with a cron job to keep it warm if it matters.

• Supabase → database + Google authentication + storage. The free tier is genuinely generous. Bonus: turn on Row Level Security (RLS) before you ship anything real, otherwise anyone with your public key can read your whole database. Ask me how I know.

• GitHub → code hosting, obviously.

That's a full-stack app, deployed, authenticated, and live on the internet, for the price of zero rupees. If startups in 2010 saw this stack they would weep.

One sacred rule: never paste API keys, database passwords, or secrets directly into your code. Put them in a .env file, add .env to your .gitignore, and configure them through Vercel/Render/Supabase dashboards. If you commit a secret to GitHub, assume the entire internet now has it. Just rotate it and move on with your life.

The one thing I wish someone had told me earlier: .md files

This is the trick. The big one. The thing that separates "AI gave me garbage" from "AI gave me exactly what I wanted."

Use markdown files, yes, those .md things you've seen on GitHub like README.md as instructions for the AI.

If you're using Claude Code specifically, there's a magic filename it looks for: CLAUDE.md. Drop it at the root of your project and Claude Code reads it automatically at the start of every session. You don't even have to remind it. (Bonus: type /init in Claude Code and it'll generate a starter CLAUDE.md based on your project. Then you trim it down to the stuff that actually matters.)

Here's how I structure my markdown context:

• CLAUDE.md → the WHY and HOW of your project. Tech stack, naming conventions, hard rules ("never use class components", "all API calls go through /lib/api.ts"), and anything Claude would mess up without being told.

• design.md → spacing, colors, typography, component style, the overall vibe. "Use Tailwind, prefer rounded-2xl, primary color is #6366F1."

• user-flow.md → user journeys, edge cases, the stuff in your head you keep forgetting to mention.

• prd.md (or spec.md) → the actual product requirements. What are you building? Who for? What does success look like?