title: "Case Study: Solo Developer Builds a SaaS MVP in Two Weeks" last_updated: 2026-03-21 status: experimental difficulty: intermediate tags: [solo-developer, saas, mvp]

Case Study: Solo Developer Builds a SaaS MVP in Two Weeks

Context

• Project type: SaaS project management tool (kanban boards, task assignments, team dashboards)
• Team size: 1 developer
• Tools used: Claude Code, Next.js 14 (App Router), Postgres via Drizzle ORM, Tailwind CSS, Vercel for hosting
• Duration: 2 weeks (10 working days)
• Budget: Tight — needed to ship on a bootstrapper's budget with minimal infrastructure cost

The developer — call her Maya — had been freelancing for three years and wanted to build a SaaS product on the side. She had experience with Next.js and Postgres but had never shipped an entire product alone in two weeks. Her previous side projects had stalled at the 60% mark, dragged down by the sheer volume of code a full-stack app requires.

Maya had been using Claude Code for about a month on client work. She was comfortable with the basics: project memory, focused prompts, reviewing diffs. She decided to push the tool harder and see whether agentic workflows could compress a 4-6 week solo build into two.

The Challenge

Building a project management SaaS is not technically novel, but the surface area is large. Even an MVP needs: authentication, team management, project CRUD, kanban boards with drag-and-drop, task creation and assignment, a dashboard with basic metrics, email notifications, and a billing integration. For a solo developer, the bottleneck is not any single feature — it is the accumulated volume of code across the full stack.

Maya needed to ship a usable product in 10 working days. Not a demo. Not a proof of concept. A product that real users could sign up for, create teams, and manage projects.

The Approach

Day 1-2: Foundation and Project Memory

Maya started by spending a full morning writing her CLAUDE.md before writing any application code. This felt counterintuitive — she wanted to start building — but her experience on client projects had taught her that a good project memory file paid for itself within the first day.

Her initial CLAUDE.md covered:

• Project overview (one paragraph)
• Tech stack with specific versions
• Directory structure conventions (where API routes go, where components go, how to organize database schemas)
• Naming conventions (camelCase for functions, PascalCase for components, snake_case for database columns)
• The build and test commands
• A "do not" section: no class components, no raw SQL (use Drizzle), no client-side data fetching for anything that could be server-rendered

She then asked the agent to scaffold the project: Next.js app with App Router, Drizzle ORM configuration, Tailwind setup, and a basic directory structure. The agent handled this in one pass. She reviewed the scaffold, committed, and moved on.

The afternoon went to authentication. This was the one feature she implemented mostly by hand. Auth involves secrets, session management, redirect logic, and security edge cases that she did not trust the agent to get right without heavy review. She used the agent to generate the boilerplate (database schema for users, basic login and signup pages) but wrote the session logic and middleware herself. Estimated split: 40% agent, 60% manual for auth.

Day 3-5: Core Features with Daily Sessions

Maya structured each day around a single major feature area. The pattern was consistent:

1. Morning planning session (15 min) — She used plan mode to have the agent analyze the next feature and propose an implementation plan. She reviewed the plan, corrected any issues, and approved it.

2. Implementation session (3-4 hours) — She worked through the plan feature by feature, using focused prompts for each piece. Database schema first, then API routes, then UI components. She committed after each completed piece.

3. End-of-day review (30 min) — She reviewed all the day's diffs, ran the app manually, and updated CLAUDE.md with anything the agent had gotten wrong that a configuration line could prevent tomorrow.

Day 3: Team management (create teams, invite members, role-based access). Day 4: Project CRUD and the kanban board layout. Day 5: Task creation, assignment, and the drag-and-drop interaction.

The drag-and-drop implementation on Day 5 was the first real struggle. The agent produced a working drag-and-drop using the HTML5 drag API, but the state management for reordering cards across columns was brittle. When a card was dragged between columns, the optimistic UI update occasionally desynced from the server state. Maya spent two hours debugging this with the agent before deciding to handle the state management logic manually while letting the agent generate the UI components and API calls around it.

Day 6-7: Sub-Agents for Parallel Frontend/Backend Work

By Day 6, Maya had enough structure in place that frontend and backend work could proceed independently. She started using sub-agents to parallelize:

• One agent session worked on the dashboard UI components (charts, metrics cards, layout)
• Another agent session worked on the backend aggregation queries and API endpoints that powered the dashboard

She used separate terminal windows and kept both sessions focused on their respective domains. The CLAUDE.md file served as the shared contract — both agents read the same conventions, used the same data models, and followed the same patterns. When the frontend agent needed to know the API response shape, it read the Drizzle schema and the API route files the backend agent had created.

This parallel approach cut the dashboard work from an estimated two days to one. The integration was not seamless — the frontend agent assumed a slightly different response format in one endpoint, which took 20 minutes to fix — but the time savings were substantial.

Day 8-9: Polish, Testing, and Edge Cases

Day 8 focused on testing. Maya used the test-first pattern: she asked the agent to write integration tests for the API routes, then ran them and fixed failures. The agent wrote 34 tests across the core endpoints. 28 passed on the first run. The 6 failures revealed real bugs — incorrect error status codes, a missing authorization check on one endpoint, and a race condition in the task reordering logic.

Day 9 was polish: email notifications (the agent handled the templates and sending logic; Maya configured the email provider manually), responsive design fixes, loading states, and error boundaries. This was the kind of high-volume, low-complexity work where the agent excelled. She would point to a page, describe the issue ("this page has no loading state — add a skeleton loader that matches the layout"), and the agent would handle it.

Day 10: Deployment and Launch

The final day was deployment to Vercel, environment variable configuration, a quick smoke test, and writing the landing page. The agent wrote the landing page copy and layout. Maya revised the copy (the agent's version was too generic) but kept the layout. She was live by 3 PM.

What Worked

Project memory evolution. The CLAUDE.md file went from 15 lines on Day 1 to 45 lines by Day 10. Each addition was reactive — something the agent got wrong, turned into a configuration line so it would not happen again. By the second week, the agent's first-pass accuracy was noticeably higher than the first week, not because the agent improved, but because the project memory had accumulated the project's specific patterns.

Checkpoint commits. Maya committed after every completed feature, sometimes multiple times per hour. This meant she could always roll back if the agent went off track. On three occasions, she reverted the agent's work entirely and re-approached the feature with a different prompt. Without frequent commits, those reversions would have been painful.

Plan mode for complex features. For anything involving multiple files or non-obvious architecture (auth, drag-and-drop, dashboard aggregations), Maya used plan mode to review the agent's approach before it wrote any code. This caught two significant architectural issues before they were implemented — once the agent planned to put business logic in a React component, and once it planned a database query that would not scale.

Daily CLAUDE.md updates. Treating the project memory file as a living document — updated at the end of every working day — created a compounding advantage. By Day 5, the agent was producing code that felt like it was written by someone who had been on the project for weeks.

Sub-agents for frontend/backend parallelism. Once the data models were stable, running separate sessions for frontend and backend work roughly doubled throughput for the dashboard feature.

What Didn't Work

Complex state management. The agent consistently struggled with state that involved coordination between multiple components. The kanban drag-and-drop, optimistic UI updates, and real-time dashboard refresh all required manual intervention. The agent could produce code that worked for the simple case but broke on edge cases involving timing, race conditions, or multi-step UI interactions.

Auth required heavy manual work. Despite clear instructions, the agent made security-sensitive decisions that Maya was not comfortable shipping without manual review and modification. Session token handling, CSRF protection, and the password reset flow all needed significant human intervention. For auth in production, the agent was a boilerplate generator, not an implementer.

Agent-written copy was generic. The landing page copy, error messages, and onboarding text all read like they were written by an AI — because they were. Maya rewrote most user-facing copy. The agent is good at generating placeholder text and structuring layouts, but the words themselves lacked the specificity and personality a product needs.

Inconsistent import patterns. Even with CLAUDE.md specifying import conventions, the agent occasionally used different import styles in different files (named imports in one file, default imports in the next). This was cosmetic but annoying to clean up across 40+ files. A hook that ran a linter after each edit would have caught this automatically.

Metrics

Key Takeaways

1. Project memory is your highest-leverage investment as a solo developer. Every line in CLAUDE.md that prevents a common agent mistake saves you correction time across every future session. Start it on Day 1 and update it daily. The compound effect is significant by the end of the first week.

2. Let the agent handle volume; handle complexity yourself. The agent excelled at high-volume, pattern-following work: CRUD endpoints, UI components, test boilerplate, responsive layouts. It struggled with work that required reasoning about state over time, security implications, or subtle user experience decisions. Knowing which category a task falls into is the key delegation skill.

3. Plan mode prevents expensive mistakes on multi-file changes. A two-minute plan review is always cheaper than a thirty-minute debugging session. Use plan mode for any feature that touches more than two files or involves non-obvious architectural decisions.

4. Commit after every completed feature, not at the end of a session. Frequent commits turn agent mistakes from setbacks into minor inconveniences. Three full reversions in 10 days sounds bad, but each one cost under two minutes because the last good commit was never far away.

5. Sub-agents work when the contract between them is clear. Parallel frontend/backend sessions worked because the database schema and API contracts were defined before the parallel work started. Without that shared contract, the agents would have made incompatible assumptions. The CLAUDE.md file acted as the source of truth both sessions could read.

What We'd Do Differently

• Set up a linter hook from Day 1. An automated lint check after every agent edit would have caught the inconsistent import patterns and saved a cleanup pass on Day 9.
• Write test scaffolds before implementation, not after. Using the test-first pattern from Day 1 (instead of saving testing for Day 8) would have caught bugs earlier and given the agent clearer success criteria for each feature.
• Use a well-tested auth library instead of building from scratch. Even with agent assistance, hand-rolling auth was the most time-consuming and highest-risk part of the project. A library like NextAuth or Lucia would have been faster and safer.
• Add response schema examples to CLAUDE.md. The frontend/backend desync on the dashboard endpoint could have been prevented by including a sample API response in the project memory file.

Patterns Used

• Fan-Out Fan-In — for parallel frontend/backend development sessions
• Plan Mode — for reviewing complex feature approaches before implementation
• Checkpoint Commits — for maintaining clean rollback points throughout the build
• Test-First Agent Pattern — for driving implementation through pre-written tests