Ship It Live — $1,999 flat
Design + build + deploy · kickoff in 24h · limited slots
Ship It Live · iOS sprint
Your iOS app, designed, built and on the App Store in 30 days.
Not a prototype and not a Figma file — a real app on a real device, in TestFlight by week three and submitted to Apple by day 30. One fixed price, agreed before anything starts.
Quick answer
An iOS app can be designed, built and submitted to the App Store in 30 days for a fixed $2,500, as long as the scope is one job the app does well. That month covers design, build, TestFlight testing and submission. Apple's review adds one to three days on top.
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–3
Scope lock
We agree exactly what the app does and, more importantly, what it does not do in v1. This is the meeting that decides whether 30 days is realistic.
- 2
Days 4–12
Design
Every screen designed and reviewed — flows, empty states, errors. You see real screens in the first week, not a moodboard.
- 3
Days 13–24
Build
The app gets built and wired to real data. A TestFlight build lands with you around day 21 so you are testing while I am still building.
- 4
Days 25–28
Polish and test
Device testing, performance, the fifty small things that separate a real app from a demo. Your feedback from TestFlight gets folded in.
- 5
Days 29–30
Submit
App Store listing finished and the build submitted to Apple. I handle review questions if they come back with any.
What $2,500 gets you
Everything needed to launch — nothing padding the invoice.
Who books this
Built for
Founders validating an idea with real users, not a waitlist
Businesses whose customers keep asking if there is an app
Teams who need something in front of investors this quarter
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
"Do you have an app?" every single week
A local service business's customers keep asking if there's an app to book or order through, and the founder has started deflecting the question because the honest answer undermines trust on a sales call.
A real TestFlight build lands by week three — something to show, not a promise, before the next customer asks.
Situation 2
Term sheet conversation, no product to show
A founder has investor interest and a call booked in five weeks, but the product is still a Figma file and a waitlist page — nothing an investor can actually hold or use.
A working app on a real device, submitted to Apple by day 30, replaces the mockup with something real for that call.
Situation 3
The agency quote was four months and a deposit
An agency scoped the same one-job app at four months with no confirmed start date, while a competitor with a worse product is already live and taking customers.
Scope lock happens in days 1-3, and design work starts within days, not months — the deadline is agreed before anything begins.
Situation 4
Eighteen months, nothing shipped, because v1 kept growing
A previous attempt at this app tried to include a dashboard, social features and messaging all in the first version, and the scope never stopped expanding long enough to launch.
The scope-lock conversation on day one decides what v1 deliberately leaves out — the actual reason 30 days is realistic.
Situation 5
One clear job, no engineer in-house
A small team knows exactly what the app should do — one workflow, one audience — but has no developer, and hiring one full-time for a single project doesn't make financial sense.
One senior team designs and builds it end to end, with source code and design files handed over so there's no ongoing dependency.
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.
Apps that need a large backend built from scratch — that is its own project, and I will scope it separately rather than pretend it fits.
Anything depending on heavy 3D, real-time video processing or games. Thirty days is not enough and I would be setting us both up to fail.
Products where you do not yet know what the app is for. We scope that first, as a small paid piece of work, then start the clock.
Inside the 30 days
- Full product design — every screen, not just the hero
- Built in React Native or Swift, whichever suits the app
- TestFlight build you can put in real hands by week three
- App Store listing: copy, screenshots, icon, privacy details
- Submission handled end to end, including review responses
- Push notifications, analytics and crash reporting wired in
- The source code and the design files are yours at handover
- 30 days of support after launch, included
Quoted as one number before day one. A week running long is mine to absorb.
Outside the line
- Apps that need a large backend built from scratch — that is its own project, and I will scope it separately rather than pretend it fits.
- Anything depending on heavy 3D, real-time video processing or games. Thirty days is not enough and I would be setting us both up to fail.
- Products where you do not yet know what the app is for. We scope that first, as a small paid piece of work, then start the clock.
Real work, sized and priced separately. You hear it before you book, not at handover.
Questions
Before you book
Yes, when the scope is one clear job the app does well. The 30 days covers design, build, TestFlight and submission. What makes it possible is deciding in the first three days what v1 does not include — apps overrun because scope grows, not because building is slow.
App Store submission inside a 30-day sprint
The timeline on this page covers design + build + submit. Store review is a separate queue you do not fully control. Plan the sprint so submission is early enough that review slip does not erase the month — without pretending the store will approve on a fixed calendar day.
What must be ready before you hit submit
| Ready item | Why it blocks submit |
|---|---|
| Final bundle / build | Reviewers install what you upload |
| Privacy labels / data disclosures | Incomplete forms bounce the submission |
| Screenshots + store description | Listing is part of the product |
| Account / entitlements access | Someone on your side must own the App Store account |
| Crash-free core path | Reviewers exercise the primary job |
iOS-specific
- Apple Developer Program membership active on your team
- Certificates / profiles under your control by submit week
- Review notes explain demo logins if the app requires an account
- Privacy Nutrition Labels match what the binary actually does
Soft planning rule (aim to — not an SLA)
Planning rule (not an SLA): aim to upload by day 25 so store review has room to move. Day 30 means the sprint build and submit package are done — not a promise that Apple or Google has finished review or that the listing is live on the store that calendar day. If review takes longer, the build is still done; the listing goes live when the store finishes.
Scope that fits 30 days vs scope that blows it
Usually fits
- One primary job on iPhone (clear home to success path)
- Auth + core CRUD or equivalent
- Push optional, not a science project
- Analytics hook
- App Store listing assets
Usually blows it (wrong sprint — say so early)
- Heavy offline sync + novel realtime as day-one requirements
- Medical/clinical claims without a compliance plan
- Also Android, the marketing site, and the brand system in the same ticket
- Multi-tenant enterprise permissions on v1
Cut list template (fill on kickoff)
- Primary user job (one sentence)
- Platforms in this sprint: iOS (iPhone primary)
- Explicitly out this month: ________________
- Decision owner (one name): ________________
If the wishlist needs three primary jobs, you need three sprints — or a different engagement. See also the hub expansion on /shipitlive for the full track map.
Design-engineering acceptance checklist (before submit)
Use this on day 28 — for us or any team you hire:
- Empty, loading, and error states for the primary flow
- Auth path (if any) recovers from wrong password / cancelled session
- Type and spacing hold up on a current iPhone size class + one smaller device
- Accessibility basics: dynamic type / content size where relevant; contrast on primary CTAs
- Analytics or logging hook installed or deferred in writing
- Store screenshot set matches the build you upload
- Source / project access transferred to your account
Craft bar: If a screen only works with perfect demo data, it is not ready.
Extra questions
Who submits to App Store?
Native vs cross-platform for this page?
What if App Store rejects the first binary?
How does this relate to AI agents (Grok Bot / Cursor)?
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.