How To Built a Production Web App Using Claude Code

Start with a Document, Not Code

The first thing we wrote wasn't a line of code. It was a Product Requirements Document — a plain-English description of what the product needed to do and why. For Flow Tracker, that meant answering questions like: Who signs in? What can they see? What happens when someone uploads a file? What does the nightly backup look like?

This document became the single source of truth for every decision that followed. Claude Code read it before touching anything. The result: no wasted work, no features built in the wrong order, no "we'll figure out auth later" shortcuts that cause headaches in production.

The guiding principle from that document: production before polish. Deploy to your real domain first. Wire the database second. Build features third. This order matters because it forces you to confront real-world constraints — DNS, SSL, environment variables — before you're deep in application logic.

Skills: Giving Claude a Rulebook

Claude Code is powerful out of the box, but we made it significantly more reliable by writing skill files — short, structured instruction sets that tell Claude how to behave in specific situations. One skill described how to use Cloudflare's platform (where the app runs). Another described the test-first workflow. A third covered how to handle errors without the fragile patterns that cause silent failures.

These skills aren't code. They're closer to a company's internal handbook — the kind of institutional knowledge that normally lives in a senior engineer's head and never gets written down. With Claude Code, you can write that knowledge once and apply it consistently across every decision.

Tests Before Code — Every Time

The single most important discipline in this build was test-driven development: write a failing test before writing any feature. Before the sign-in page existed, there was a test that said "a non-org email address must return 403." Before the audit log existed, there was a test that said "a POST request must produce a database row." Before role-based permissions existed, there were nine tests mapping every combination of user role and project membership to the expected outcome.

This matters for a non-technical reader because it changes the nature of the build conversation. Instead of asking "did you build the thing?", you ask "does the thing pass its tests?" That's a verifiable, objective answer — not a matter of interpretation. It also means that as new features were added, every previous guarantee was automatically re-checked. Nothing quietly broke.

One Build, End to End

With the PRD and skill files in place, the build ran as a single continuous effort. A live URL and working database came first. Then automated tests and a CI pipeline that blocked any bad code from reaching production. Then features built in parallel by multiple AI agents running simultaneously — comments, file attachments, multiple projects, structured logging — work that would have taken a human team weeks, completed in a fraction of the time.

The final layer added role-based access control, a compliance-grade audit log capturing every change, a nightly database backup, a welcome email for new users, and a browser interface — a Jira-style kanban board — so teammates could use the product without needing to know any API commands.

What This Changes

The most striking part of this process wasn't the speed. It was the discipline. Claude Code, guided by the PRD and skill files, made fewer shortcuts than most human developers under deadline pressure. It wrote tests before code. It never bypassed security checks. It asked before doing anything irreversible.

For non-technical founders, product managers, or team leads: the limiting factor is no longer "can we build this?" It's "can we describe clearly what we want?" Write that down with enough precision, give it to Claude Code with the right skills and a test-first workflow, and the build largely takes care of itself.

The full Flow Tracker codebase — auth, database, API, browser UI, backup, audit log — is running in production today, on a custom domain, at roughly $5 a month in infrastructure costs. No engineering team required.