Most fights between a founder and an app developer start with money, and most of those start with a schedule that paid for time instead of for things you could check. A good app development milestone payment schedule ties every payment to something you can open, click or install on your own phone. If you can’t verify it, you shouldn’t be paying for it yet.
Below is how we think a schedule should be built, what each milestone should hand over, and where the money should sit. It applies whether you hire us, another studio or a freelancer you found last week.
What an app development milestone payment schedule is for
A milestone schedule does two jobs. It keeps the developer funded so they aren’t working at a loss, and it keeps your exposure small, so a bad engagement costs you one milestone rather than the whole budget. Both matter. Developers who are squeezed upfront cut corners or drift away to better-paying work, and clients who pay most of the budget before seeing working software have no leverage left.
The rule we use is simple: at any point, what you’ve paid should roughly match what you’ve received in a form you can keep. Code in your repository counts. A design file shared to your account counts. A status update saying “70% done” doesn’t.
The milestones, and what each one should deliver
Projects differ, but most app builds pass through the same five phases. Here’s what “done” should mean at each one.
1. Discovery and scope
A written scope document listing screens, user roles, integrations (payments, maps, push notifications, analytics), what’s explicitly out of scope, and the acceptance criteria for every later milestone. Often a clickable prototype too. This milestone is small and should be paid in full on delivery, because the document is useful to you even if you walk away and take it to someone else. That’s the point of it.
2. Design sign-off
Final UI for every screen in scope, in a design file you own, including the states people forget: empty lists, errors, loading, no network. Sign this off before serious build work begins. Changing a design after it’s coded costs several times what it costs in Figma.
3. Core build
A working build of the main flows on real devices: TestFlight for iOS, an internal testing track on Google Play, or a staging URL for web. Code pushed to a repository you own, with real commit history. You should be able to sign in, do the main thing the app exists to do, and see the data land on a real backend. On larger projects this phase splits into two or three milestones, each one a feature set you can test on its own.
4. Integrations and hardening
Payments working in sandbox and then live, push notifications, analytics, admin tools, edge cases, and a test pass against the acceptance criteria written in milestone one. This is where projects quietly slip, because payment gateways, store review rules and background location each come with their own surprises. When we built a payment portal with several Indian gateways for an ed-tech client, refunds and post-payment reconciliation needed as much care as the checkout screen.
5. Launch and handoff
The app live in the stores or on your domain, under your developer accounts, with documentation, environment setup notes, credentials transferred and a defined warranty period for bugs. Handoff has money attached for a reason. If the final payment is tiny, nobody is motivated to write the README.
How to split the money across milestones
We won’t hand you percentages that pretend to fit every project. A few principles hold anyway:
- A modest advance is fair. A developer who blocks out weeks of their calendar for you is taking a risk too. An advance covering discovery, or a small share of the first build milestone, is normal. One covering half the project isn’t.
- Weight payments toward things you can test. Design and core build should carry the larger amounts, because that’s where most of the work is and where you can see it.
- Keep a meaningful final payment. Hold back enough for launch and handoff that finishing properly is worth the developer’s time: store submission, credential transfer, documentation.
- Pay against acceptance criteria, not dates. “Milestone 3 due 15 March” is a deadline. “Milestone 3: a user can sign up, place an order and pay in sandbox on iOS and Android” is a milestone. Payment follows the second.
- Agree a review window. Give yourself a fixed number of working days to test each delivery and raise issues, after which silence counts as acceptance. This protects the developer from a client who sits on a delivery for a month.
Watch for problems on either side. A schedule where the developer is paid mostly by elapsed time is one. Another is a contract that lets the client withhold payment for subjective reasons (“it doesn’t feel right”). Both end badly, usually around milestone three.
How we run fixed-price milestones at orithLabs
We’re a two-founder studio in Delhi NCR and we work on fixed-price milestones for almost every build. In practice that looks like this:
- We start with a paid scoping phase. You keep the output, a document where every later milestone is defined by what you’ll be able to test.
- Each milestone has a fixed price agreed before it starts. If we underestimate, that’s on us.
- Code lives in your repository from the first commit, and builds go to your own TestFlight and Play Console accounts.
- Anything new goes through a written change request with its own price and its effect on the timeline, approved before we touch it. No surprise invoices at the end.
- The people who scope the work write the code, so the estimate isn’t a salesperson’s guess handed to someone else.
Fixed price has a cost. We push hard for a clear scope up front, and we’ll refuse to price a vague item until it’s specific enough to test. Some clients find that slow at the start. We’d still take it over discovering in month three that “admin panel” meant something different to each of us.
A quick checklist before you sign
- Does every milestone name a deliverable you can open or install?
- Are there written acceptance criteria for each one?
- Is the advance small relative to the total?
- Is the final payment big enough to make a proper handoff worth doing?
- Do you own the repository, the design files and the store accounts from day one?
- Is there a written change request process with prices?
- Is there a review window, and a warranty period after launch?
If you’ve been sent a schedule and want a second opinion, or you’d like to scope a build this way from the start, our product strategy and scoping work is where orithLabs would begin. We’re glad to look it over even if you end up building with someone else.