Journal · Playbook
How we ship a working app in 7 days, end to end
The exact process we use to take a founder from a Figma sketch to live, paying customers in a single week. No magic — just brutal scope discipline and a few opinionated tools.
"Can you really ship an app in a week?" — yes, with caveats. We've done it for nine clients, all founders trying to validate something with real users instead of another customer-discovery deck. Here's the playbook, day by day.
Monday — Listen, decide, cut
We do one 90-minute kickoff call. Half of it is the founder explaining their vision. The other half is me, sometimes painfully, cutting that vision down to one thing.
The question I ask, usually around minute 60: "What is the single thing this app needs to do, that if it doesn't do it, the product doesn't exist?" Everything else is a v2 candidate.
- Pick the one core flow.
- Pick the data model — usually 3–5 tables.
- Pick the stack. (We default to Next.js + Postgres + Stripe + Resend. We pick differently maybe 1 in 10 projects.)
- Set the launch metric. "10 paying users by Sunday night" is a real one we used.
Tuesday — Sketch, then skeleton
Morning: I sketch the screens in Figma. Not pretty. Boxes and arrows. The founder reviews on a 30-min call at 2pm. We adjust until they say "yes, that's the thing."
Afternoon: I scaffold the project. Database, auth, deployment pipeline, domain. By end-of-day Tuesday, there's a live URL with a login screen and a database that responds. Nothing actually works yet. But the thing exists in the world.
The single biggest unlock of a 7-day MVP isn't speed. It's that the founder sees the URL on Tuesday night and goes, "wait — it's real." That changes how they treat the rest of the week.
Wednesday — Build the spine
This is the longest day. I build the core flow end-to-end, but ugly. Routes, forms, database writes, the API call that makes the magic happen. No styling beyond default Tailwind. The founder can log in and click through the whole thing by 8pm.
Thursday — Make it look like the product
Now we add design. Type, color, real components, real spacing. This is where we use the brand if there is one, or pick fast if there isn't. By end of Thursday it looks like an app you'd pay for, not like a project.
If payments are part of the launch, this is also Stripe day. Webhooks, subscription handling, customer portal. It's tedious and unglamorous and matters a lot.
Friday — Polish, edge cases, the boring half
Friday is what separates an MVP that survives launch from one that doesn't:
- Empty states — what does the dashboard look like for a brand-new user?
- Error states — what happens when the API call fails?
- Mobile — every screen, on a phone, in a parking lot.
- Email — welcome, password reset, receipt. Real templates.
- Analytics — we wire Plausible or PostHog so we can see usage on Sunday.
Friday is unsexy. The founder usually wants to add a feature. We don't.
Saturday — Soft launch with 5 people
The founder picks 5 people from their network. Friends who'll be honest. We watch them use it on a video call with screen-share. We don't help. We watch.
We always — always — find 3 things that need to change. Not feature requests. Friction. Confusion. A button labeled wrong. A form that needs a default value. We patch them Saturday night.
Sunday — Launch
The founder posts to LinkedIn / Product Hunt / X / their list. Whatever channel they have. The product is real. People can sign up. Stripe charges them. Emails go out.
I'm on standby. Last week's launch had two real bugs in the first hour. We fixed them in eleven minutes each.
What this week doesn't include
Things we explicitly do not do in a 7-day build, and that we tell founders up front:
- An admin panel. (We use the database directly. It's fine.)
- A pricing page with three tiers. (One price, one product, one button.)
- An app for iOS. (The web version works on a phone. That's enough.)
- SOC 2. (You will have zero customers asking on day one.)
- "What if we have a million users." (You won't, on day one. Build for it when you have a hundred.)
Why this works (and when it doesn't)
It works because most early-stage products fail for reasons unrelated to engineering. They fail because the founder built the wrong thing for too long. A 7-day MVP forces a brutal conversation about what the product actually is, before too much money or ego is in it.
It doesn't work for everything. Hardware. Regulated industries. Anything where the v1 needs to be enterprise-secure or HIPAA-compliant. We tell people that on the kickoff call. Most of the time, what they think is "regulated" is actually solvable in a week.
If you're sitting on an idea that's been in a slide deck for six months, you can probably ship it next week. Send us a line. We'll know on the first call whether it's a 7-day project or something different — and we'll tell you, plainly, either way.