Ship It Live — $1,999 flat
Design + build + deploy · kickoff in 24h · limited slots
Ship It Live · MVP sprint
A SaaS MVP with real users, live in 30 days.
Not a landing page with a waitlist. A product people can sign up for, use and pay for — deployed on your domain inside a month, at a price agreed before it starts.
Quick answer
A SaaS MVP with authentication, billing and a working database can be designed, built and deployed in 30 days from a fixed $2,500. The month covers the one workflow your product charges for — not the full roadmap, which is what makes the deadline hold.
The plan
Day one to day 30, written down.
You get this schedule before you commit, not after. If a phase slips, that is mine to absorb — the price and the date were agreed before anything started.
- 1
Days 1–4
Find the one workflow
Every SaaS has one job people would pay for today. We identify it and cut everything else out of v1. This conversation is the difference between shipping and slipping.
- 2
Days 5–13
Design
The core workflow designed properly — including onboarding and empty states, which is where most MVPs quietly lose their users.
- 3
Days 14–25
Build
Auth, database, billing and the workflow itself. A staging URL goes live early so you are clicking through it well before launch.
- 4
Days 26–28
Billing and edge cases
Payments tested properly — failed cards, cancellations, upgrades. The unglamorous part that decides whether you actually get paid.
- 5
Days 29–30
Launch
Live on your domain, monitoring on, marketing page up and the first real sign-up walked through together.
What from $2,500 gets you
Everything needed to launch — nothing padding the invoice.
Who books this
Built for
Founders who need paying users before they need a roadmap
Operators productising something they already do manually
Teams who have been quoted six months and $60,000 for this
Real situations
Five ways this shows up, and what actually fixes it.
Not hypothetical — the shape of the problem before someone books this sprint, and the specific part of the build that resolves it.
Situation 1
Quoted six months and $60,000 for a first version
A founder productising something they already do manually for clients got a development quote of six months and five figures for what is, at its core, one workflow with auth and billing.
The one workflow people would pay for today gets identified in days 1-4, and the whole MVP ships in 30 days from a fixed $2,500.
Situation 2
A landing page with a waitlist, no product behind it
A founder has been collecting emails on a waitlist for months, but there's no actual product people can sign up for, use, and pay for — just a promise.
By day 30, there's a real deployed product with sign-up, a working database and Stripe billing, not another page collecting intent.
Situation 3
Manually doing the job the SaaS should automate
An operator is delivering their service by hand — spreadsheets, emails, manual follow-ups — and knows it should be software, but has never shipped anything technical before.
The core workflow gets designed and built around exactly what they already do manually, so the product mirrors a proven process from day one.
Situation 4
Roadmap ready, but nothing to charge for yet
A team has a full year of planned features mapped out but hasn't shipped the one thing that would let a single customer pay them today.
Days 1-4 are spent cutting everything except the one paid workflow — the roadmap waits until someone is actually paying.
Situation 5
Billing was an afterthought in a previous build attempt
A previous MVP attempt got the interface built but never wired up real payments, so it technically worked but couldn't actually generate revenue.
Stripe subscription billing — including upgrades, failed cards and cancellations — is built and tested in days 26-28, before launch, not after.
The honest part
When 30 days is the wrong answer.
A fixed deadline only works when the scope genuinely fits inside it. These are the cases where I will tell you so rather than take the booking.
Products needing enterprise features on day one — SSO, audit logs, granular permissions. Those come after someone is paying, not before.
Marketplaces with two-sided liquidity problems, which are a business challenge before they are a build challenge.
Anything where the core is a hard technical research problem rather than a product to assemble.
Inside the 30 days
- Product design for the core workflow, end to end
- Sign-up, login, password reset and account management
- Subscription billing wired to Stripe, including the upgrade path
- A real database, not a spreadsheet behind a form
- Deployed on your domain with monitoring in place
- A marketing page that explains and sells the product
- Source code and design files yours at handover
- 30 days of post-launch support, included
Quoted as one number before day one. A week running long is mine to absorb.
Outside the line
- Products needing enterprise features on day one — SSO, audit logs, granular permissions. Those come after someone is paying, not before.
- Marketplaces with two-sided liquidity problems, which are a business challenge before they are a build challenge.
- Anything where the core is a hard technical research problem rather than a product to assemble.
Real work, sized and priced separately. You hear it before you book, not at handover.
Questions
Before you book
Yes, when it does one thing people would pay for. The month covers design, auth, billing, database and deployment for that single workflow. MVPs overrun because the feature list grows, which is why days one to four are spent deciding what to leave out.
The one-workflow rule (how we pick v1)
A 30-day SaaS MVP is not a roadmap in a trench coat. Days one to four on this page already say the month is spent deciding what to leave out. This section is the filter we use on the call.
| Lock this | Or it is not this sprint |
|---|---|
| One primary workflow a buyer would pay for | “Platform” with three audiences |
| One buyer role (who pays / who logs in daily) | Everyone’s wishlist merged |
| One charge event (subscription, seat, or usage — pick) | Pricing experiments with five SKUs |
| Explicit out-of-scope list | “We’ll squeeze it in” |
Kill criteria (examples): multi-tenant enterprise permissions on day one; native iOS + Android in the same ticket; marketplace two-sided liquidity as v1; rebuilding your whole company OS.
If the real pain is an internal spreadsheet your team runs on — not a product you charge strangers for — use /shipitlive/internal-tool-in-21-days instead. Different job, different acceptance bar.
Billing on the critical path (not polish week)
The live timeline already includes a “Billing and edge cases” block. Treat it as a gate, not a nice-to-have.
Must be true before launch week
- Plan shape agreed (what the customer pays for)
- Happy-path checkout works on production keys you control
- Failed payment / past-due path defined (even if simple)
- Who can comp a seat or refund — named human
- Tax/VAT/display rules: deferred in writing if out of scope
Processor choice stays soft here — pick what fits the stack on the call; we do not advertise a vendor partnership we have not verified for your account.
Launch bar for “real users”
“Real users” on this page means people on production, invited on purpose — not a staging URL with seed data and hope.
| Ready | Not ready |
|---|---|
| Production URL + auth | Preview-only deploy |
| One onboarding path to the paid job | Six empty feature doors |
| Empty / error / loading states on that path | Happy-path demo only |
| Admin way to disable a bad account or key | No kill switch |
| You own the auth + billing accounts | Credentials stuck in a contractor login |
No activation rates, conversion lifts, or revenue claims in this expansion — none are verified for a generic sprint page.
Craft that usually decides whether strangers trust v1: clarity of the primary table/flow, not the marketing site. For table UX patterns see data table design best practices; for dashboard references best dashboard designs.
Sibling sprints (when this slug is wrong)
- Internal ops system of record → /shipitlive/internal-tool-in-21-days
- AI-shaped product (evals, failure UX) → /shipitlive/ai-app-in-30-days
- Bounded agent job → /shipitlive/ai-agent-in-21-days
- Prototype already exists → /shipitlive/vibe-coding-to-production
- Map → /shipitlive
Extra questions
Existing FAQ already covers 30-day feasibility, cost, payments inclusion, stack, multiple workflows, and code/data ownership.
Native mobile in the same 30 days?
Who owns the Stripe (or billing) and auth accounts?
Can AI agents replace the design engineer on this sprint?
Other sprints
30 days from now, this could be live.
A 30-minute call decides whether the scope fits. If it doesn't, I'll tell you what would.