The solo developer playbook: how I ship apps in 7 days

I ship full-stack apps in seven days. Not prototypes — actual deployed products with auth, databases, payments, and real users. I'm a solo developer, and I do this for clients full-time. People who haven't tried it assume it's impossible or that I'm cutting corners. Neither is true.

This post is the playbook. Not motivational, not theoretical — the actual workflow, the actual stack, the actual constraints I operate under. If you're a solo dev who wants to ship faster, or a founder evaluating whether a "7-day MVP" is real or marketing, this is the answer.

The thesis

Most software projects take much longer than they should because they accumulate decisions. Not engineering work — decisions. What stack? What database? What hosting? What auth provider? What payment processor? What design system? What testing strategy? What CI/CD?

A team of three engineers debating each of these takes three days. A solo dev who's already made every one of those decisions across 20 prior projects takes zero days. The decisions are pre-baked.

That's the whole trick. Speed is decisions amortized over many projects. Everything else is execution.

The stack I default to

I use the same stack for nearly every project. Familiarity beats novelty when you're optimizing for shipping speed.

Next.js 14 (App Router). Server components, file-based routing, API routes in the same codebase. One mental model for the whole stack.

TypeScript, strict mode. Catches bugs at compile time that would otherwise eat afternoon debugging sessions.

Tailwind CSS. Custom design system in 30 minutes by editing tokens, not 30 hours building a component library.

Supabase. Postgres + auth + storage + realtime in one. Row-level security for multi-tenant safety.

Drizzle ORM. Type-safe SQL on top of Supabase. Cleaner than the official client when queries get complex.

Stripe. For payments. Polar as alternative for digital-product MVPs.

Vercel. For deploys. Zero-config, edge-distributed, preview URLs per branch.

Replit. For development. Persistent dev environment in a browser tab. Means I can develop from any machine.

Claude Code. For pair-programming. Reads my repo, suggests edits, runs my tests, explains decisions.

These nine tools cover 90% of what I build. The remaining 10% is one of: Expo + EAS Build (mobile), Electron (desktop), n8n (automation workflows), Resend (email), Plausible (analytics).

The seven-day rhythm

Here's what each day actually looks like on a typical 7-day MVP build.

Day 0 — Scoping (paid, separate)

A 30-minute call or a Loom exchange. Goal: turn the founder's "I want to build X" into a one-page spec listing screens, user flows, and explicit non-goals.

The most important word in this conversation is "no." I push back on every nice-to-have that doesn't help validate the core hypothesis. Real exchanges:

• "Can it have a mobile app?" → "Not for the MVP. Mobile-responsive web is fine for v1. We can add native after we know users want this."
• "We need an admin panel." → "For 100 users you don't. Run admin queries directly in Supabase. Build the panel after you have something to manage."
• "Multi-tenant from day one?" → "If your buyers are companies, yes — single-tenant is a trap that's expensive to undo. If your buyers are individuals, no — single-tenant is fine."

The output of this day is a written scope I send back. The founder approves it. We don't start the build until they do.

Day 1 — Foundation

Repo setup, dependencies, design tokens, auth flow, database schema, deploy pipeline. By end of day 1, the live URL works, login works, and there's a deployed "Hello, [user]" page.

This is the most boring day and the most important. Anything that goes wrong here cascades. So I do nothing creative on day 1 — every decision is the same as my last 20 projects, executed by muscle memory.

The deliverable at end of day 1 is a Loom: "here's the live URL, here's how login works, here's the database schema, here's the deploy pipeline. Tomorrow I start on feature X."

Day 2 — Core feature, version 1

The single most important user flow, ugly version. No design polish, no edge cases handled, no empty states. Just: the user can do the core thing the product exists to enable.

By end of day 2, the founder can use the product to do the thing it's supposed to do. It looks bad. It's not done. But it works.

The deliverable is another Loom. The founder uses the product. Almost always they say "oh, what about X?" — and 80% of the time, X is something I'd already noted as a v1.1 item. We negotiate which "what about Xs" sneak into the MVP and which become post-launch tickets.

Day 3 — Polish + secondary flows

Now I add the design system, hover states, loading states, empty states, error messages. The product starts to look like a product.

I also add the secondary flows: settings, account management, basic dashboard. These get the lightest possible treatment — functional, ugly, fixable later. The MVP is the core flow; everything else is scaffolding.

Day 4 — Payments + auth polish

Stripe checkout wired. Webhooks handling. Subscription state synced to the database. Subscription gating on the right routes. Email receipts.

This day is non-negotiable. Apps without payment are toys. Apps with broken payment are worse than apps without — they erode trust. So the payment layer gets a full day of careful work and explicit testing.

Day 5 — Edge cases + the boring stuff

Forgotten password flow. Email verification. Inviting team members (if multi-tenant). 404 page. 500 page. Privacy policy and terms of service (links to your lawyer's docs, hosted with my standard template otherwise). Robots.txt. Sitemap. OG images.

This is the day where 30% of projects bloat. Every "small thing" added on day 5 is a potential bug surface for launch day. I'm ruthless about cutting on day 5.

Day 6 — Real testing + handoff prep

The first time I test the product like a real user would. Try every flow on a real iPhone, a real Android, a real Chrome window in incognito mode, a real Firefox window. Find what breaks. Fix what breaks.

Set up the handoff package: README, environment variables doc, deployment instructions, Loom walkthrough explaining the architecture, a list of "things you should know about this codebase."

Day 7 — Launch + handoff

Deploy to production domain. Pointed at correct DNS. SSL working. Custom emails sending. Stripe in live mode (not test mode). Final QA pass. Loom delivered. Invoice sent.

Two-week post-launch fix window starts now. Most clients don't need it; the ones who do, I respond to within a day.

What makes 7 days possible

Five constraints that I'm strict about. Violate any one and the timeline slips.

1. One project at a time

I work on exactly one client project per week. No context-switching. No "quick favor for an old client." Other inquiries get told "I'm in a build until next Friday, I can chat then."

This sounds obvious; it's the single most violated rule among solo devs. The instinct when business is good is to take everything that comes in. But two half-built projects ship in 2-3 weeks combined, while two full-attention projects ship in 2 weeks. Sequencing wins.

2. Same stack, every time

I don't experiment with new frameworks during client builds. If I want to try Svelte or Bun or some new ORM, I do it on a personal project where slipping the timeline costs only my time.

This sounds boring. It is boring. It also means I move at full speed because I know exactly which patterns work for every problem I encounter.

3. Pre-built starter, every time

I have a private starter repo with the entire foundation pre-built: auth flow, design tokens, deploy pipeline, basic database schema, common API routes. Every new project clones this repo and customizes from there.

The starter saves about 6 hours per project. Over 50 projects, that's 300 hours — almost two months of work. Recovered.

4. Daily Loom updates

Communication overhead is the biggest hidden time-cost in client work. A 5-minute Loom every weekday eliminates 90% of "wait, I thought we were doing X" conversations. The client knows what's happening. They can course-correct early. They feel taken care of.

This is also a forcing function. Knowing I have to record a coherent update every day makes me actually finish coherent things every day.

5. Hard scope discipline

The MVP scope is fixed at the kickoff call. New requests during the build get logged as "v1.1 candidates" and shipped after launch, not folded into the build.

This requires saying no to your client, which is uncomfortable but is also what they're paying you for. A builder who agrees to every request during the build is going to ship in 14 days, not 7, and the client will resent the missed deadline more than they would have resented hearing "no" upfront.

The mental model: ship-then-improve

The hardest mental shift for solo devs going from "perfectionist" to "shipper" is internalizing that shipped is better than good.

Every feature you don't ship is theoretical. Theoretical features don't get user feedback. Without user feedback, your "improvements" are guesses about what users want, not responses to what users actually do.

So my heuristic is: ship the smallest version of every feature, then improve based on real usage. Empty states say "nothing here yet." Onboarding is a 30-second video, not a guided tour. Edge cases trigger "something went wrong, contact support" and a clean error log so I know to fix it. None of these are good. All of them are sufficient for the first 100 users.

This is hard because it feels lazy. It isn't. It's discipline. The lazy version is shipping the polished feature six months late.

What I actually use AI for

I use Claude Code daily. People ask whether AI replaces solo devs. The honest answer is: not yet, but it's a force-multiplier for solo devs who already know what they're doing.

What I use AI for:

• Boilerplate. "Add a settings page with these fields wired to Supabase." It writes the form, the API route, the migration. I review the diff. Saves about 30 minutes per such task.
• Refactoring across files. "Rename this type from User to Member everywhere it's used." Mechanical work that AI does correctly and fast.
• Reading unfamiliar code. "Walk me through this 60K-line client codebase I just inherited." Saves a day of orienting.
• Writing tests. "Generate Vitest tests for this function covering the edge cases." Then I review.
• Explaining error messages. "What does this Supabase RLS error mean?" Faster than searching.

What I don't use AI for:

• Architecture decisions. AI happily suggests adding three abstractions where one would do. Resist.
• Naming. It picks generic names. I want specific ones.
• Knowing when to stop. Without explicit "do exactly X, don't refactor anything else," AI scope-creeps cheerfully.
• Final review of anything user-facing. Hallucinated copy, wrong dates, "lorem ipsum" left in production. Always read the diff.

What I tell people thinking about going solo

Most engineers at big tech companies could ship more in a week as a solo dev than they ship in a month as a salaried engineer. The math is brutal:

• 8-hour day at a corporate job → ~3 hours of actual focused work, the rest is meetings, code review, planning, Slack
• 8-hour day as a solo dev → ~7 hours of actual focused work, no meetings, no review (you're the reviewer)

That 2.3x productivity multiplier is what makes 7-day MVPs real. I'm not faster than the FAANG engineer at the keyboard. I just spend 2.3x more of my day at the keyboard.

The downsides are real too. No one to bounce architecture decisions off. No one to catch your bugs in code review. Sales, accounting, and customer support are all you. Insurance, taxes, retirement — also you. Vacation = no income.

If you're considering going solo, run a 3-month experiment first while still salaried. Take on one client at a time on weekends. See if the rhythm fits. Most engineers who try solo come back to salaried roles within a year. A few don't, and those few build careers that compound dramatically over 5-10 years.

The ceiling

A 7-day MVP is the right shape for one specific kind of project: a single-feature product with a clear user flow, validated demand, and a founder who can articulate what they want.

It's not the right shape for:

• Truly novel products where the user flow itself needs to be discovered through prototyping
• Regulated industries (healthcare, finance) where compliance work eats more time than features
• Multi-stakeholder projects where coordination between client teams is the bottleneck
• Projects with large existing codebases that need to be understood before changes are made

For those, the right answer is a longer engagement (3-12 weeks), not a 7-day sprint. Sometimes I quote the longer engagement. Sometimes I refer the project to an agency or another solo dev whose strengths fit better.

The 7-day MVP works for the right shape. Knowing that shape is part of the skill.

What this gets you, what it doesn't

A 7-day MVP gets you:

• A product real users can use, in front of real users, in seven days
• Validation of your core hypothesis (does anyone want this?)
• A working codebase you can extend or hand off
• A live URL you can pitch from

A 7-day MVP doesn't get you:

• A polished, scalable, enterprise-ready product
• Comprehensive test coverage
• Optimization for millions of users
• A complete design system

Those come later. They come after you know whether the product is real. Building them first is a vanity move that founders pay for in time, not just money.

If you're a founder, the question is never "what's the most polished thing I can ship?" The question is "what's the smallest thing I can ship that proves my hypothesis?" Once you've answered that, finding a builder who can ship it in a week is straightforward.

---

If you're a founder thinking about a 7-day MVP — start a project. See pricing, recent case studies, or the FAQ. I respond within 2 hours during EU business hours.