Ship It Live — $1,999 flat
Design + build + deploy · kickoff in 24h · limited slots
Ship It Live · web app sprint
A working web app, live in 21 days.
The dashboard your team runs on spreadsheets. The portal your clients keep asking for. Designed, built and live in three weeks, at a price agreed before it starts.
Quick answer
A focused web app — an internal tool, dashboard or customer portal — can be designed, built and deployed in 21 days from a fixed $1,999. Three weeks is enough when the app has one clear audience and one clear job, with data and access decided up front.
The plan
Day one to day 21, 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–3
Map the process
How the work happens today, where it breaks, and which parts the app should own. Usually shorter than expected because you already know.
- 2
Days 4–9
Design
Screens, states and permissions designed and reviewed. Internal tools live or die on density and speed, so both get decided deliberately.
- 3
Days 10–17
Build
Database, access control and the interface, with a staging URL early so your team can click through it while there is still time to change things.
- 4
Days 18–19
Migrate and test
Your existing data imported and checked. This is usually the fiddliest part and it gets its own time rather than being squeezed into launch day.
- 5
Days 20–21
Launch
Live, with your team walked through it and the old spreadsheet archived rather than quietly kept open.
What from $1,999 gets you
Everything needed to launch — nothing padding the invoice.
Who books this
Built for
Teams running a critical process on a spreadsheet nobody trusts
Businesses whose clients want a portal instead of email threads
Operators who know exactly what they need and want it built
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
A critical process still lives in a shared spreadsheet
A team runs a genuinely important part of the business — bookings, inventory, client status — through a spreadsheet that everyone is quietly afraid to touch, because one wrong formula breaks everything downstream.
Days 1-3 map exactly how the process runs today, and by day 21 it's real software with roles, permissions and a proper database instead.
Situation 2
Clients keep asking for a portal instead of email threads
A service business manages every client update over email, and clients have started asking, politely at first, whether there's 'a place to log in and see status' instead.
A client portal ships in three weeks, with logins, roles and the specific views and exports clients actually asked for.
Situation 3
Knows exactly what's needed, just needs it built
An operator has spent months refining exactly what the internal tool should do — no discovery phase needed — but has no way to turn that clear spec into working software.
With the process already mapped, days 4-9 go straight to design, and a staging URL is live by day 10 for early review.
Situation 4
Paying per seat for a tool that fits two-thirds of the process
A team pays a growing monthly bill for off-the-shelf software that handles most of their workflow but forces awkward workarounds for the parts that don't fit its model.
A tool built around the actual process, not a vendor's assumptions, replaces the workaround entirely — and the source code is owned outright.
Situation 5
Old system's data needs to move somewhere real
A business has years of records in a spreadsheet or a discontinued tool and dreads the idea of manually re-entering everything into whatever replaces it.
Days 18-19 are reserved specifically for importing and checking existing data — treated as its own phase, not squeezed into launch day.
The honest part
When 21 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.
Apps needing deep integration with legacy enterprise systems, where the integration is the project.
Anything requiring compliance certification — HIPAA, SOC 2 — which is a programme, not a three-week build.
Processes nobody has agreed on yet. If the team disagrees about how the work should happen, software will not settle it.
Inside the 21 days
- Product design for the whole tool, not just the main screen
- Login, roles and permissions appropriate to who uses it
- A real database with import from whatever you use now
- The views, filters and exports people actually asked for
- Deployed on your domain or inside your infrastructure
- Responsive, so it works on the phone as well as the desk
- 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
- Apps needing deep integration with legacy enterprise systems, where the integration is the project.
- Anything requiring compliance certification — HIPAA, SOC 2 — which is a programme, not a three-week build.
- Processes nobody has agreed on yet. If the team disagrees about how the work should happen, software will not settle it.
Real work, sized and priced separately. You hear it before you book, not at handover.
Questions
Before you book
An internal tool, an admin dashboard, a client portal, a booking system, a CRM for how you actually work. One clear audience, one clear job. If it needs several unrelated modules it is bigger than a 21-day sprint and I will scope it properly.
One workflow, not a platform
A 21-day web app is one authenticated workflow in production — not a clickable prototype deck and not a multi-module platform.
Write the job before the stack
When [primary actor] needs to [job], they use this app instead of [spreadsheet / email / workaround], and success looks like [observable event] (saved, submitted, assigned, exported).
If you need several unrelated modules on day one, it is bigger than this sprint — we scope it properly instead of pretending 21 days covers a platform.
| Belongs in this 21-day sprint | Switch slug / separate project |
|---|---|
| One audience, one primary workflow | Multi-product “company OS” |
| Auth + roles needed for that job | Native App Store / Play shipping → mobile cluster |
| Your data model cut for v1 | Heavy AI eval harness → /shipitlive/ai-app-in-30-days |
| Internal ops tool shape | Narrower internal-only framing → /shipitlive/internal-tool-in-21-days |
| Billable multi-tenant SaaS shape | /shipitlive/saas-mvp-in-30-days |
Auth + data that must exist in v1
The live timeline already assumes access and data are decided up front. Make the minimum concrete.
v1 checklist (process language)
| Piece | Done-when looks like |
|---|---|
| Sign-in path | Users who should get in, get in; others do not |
| Roles (if needed) | Only the roles the workflow requires — not a full IAM product |
| Data model cut | Tables/fields for the job; rest deferred |
| Import (if scoped) | Existing records checked — treated as its own phase, not launch-day squeeze |
| Backup / export expectation | You know how to get data out if accounts move |
Soft planning markers (not an SLA): map the process early; staging URL for review mid-sprint; import window before you call it done when data move is in scope.
Default bias at handoff: cloud / auth vendor accounts in your name so you own the relationship.
Production bar
“Live” for an app means real users on a production URL — not staging cosplay.
Done-when checklist
- Production URL on HTTPS
- Auth works for the agreed roles
- Primary workflow completable end-to-end
- Error / monitoring hook if scoped on the call
- Admin escape hatch for the named owner (reset, disable, export — whatever the charter needs)
- Staging reviewed → production cutover owned
We do not invent MAU, uptime %, or performance numbers here. Soft production-ready wording: the agreed workflow runs for real users on production, with a path to see and fix breaks.
Extra questions
Existing FAQ already covers what counts as a web app, cost, data migration, infrastructure, post-launch changes, and whether the team can use it without training.
Native mobile in the same 21 days?
Who owns cloud / auth vendor accounts?
Internal tool vs SaaS MVP vs this page — which slug?
Internal tool: ops-team-shaped tool — /shipitlive/internal-tool-in-21-days.
SaaS MVP: billable product path — /shipitlive/saas-mvp-in-30-days.
If you are unsure, say the audience and the success event on the call — we pick the sharper slug.
Agents / AI in the same sprint?
Is day 21 a guarantee the app never breaks?
Other sprints
21 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.