App Development Payment Schedule: Milestones, Deposits & Timeline

If you’ve never hired a developer before, the money side of an app project can feel murkier than the technical side. Do you pay everything upfront? Only at the end? What happens if the project runs long or the developer disappears halfway through?

This guide covers three related questions people search for: how to pay a developer while you’re building an app (deposits, milestones, and a sample developer schedule), how fixed-price and time-and-materials billing differ, and, because the phrase trips people up, how Apple’s own developer payment schedule works once your app is earning money.

Quick Answer

Most app development payment schedules split the total cost into a deposit at signing (commonly 20-50%, depending on project size), two or more milestone payments tied to specific deliverables such as approved designs, a working build, or passed testing, and a final payment at launch or acceptance. Separately, if you’re asking about Apple’s developer payment schedule: Apple pays App Store developers monthly, roughly 33 days after the end of each Apple fiscal month, provided you have a Paid Applications Agreement, banking details, and meet the minimum payment threshold.

How Milestone-Based Payment Schedules Are Structured

A milestone is a defined, checkable point in the project, not just a date on the calendar. Good milestones read like “UI/UX designs approved,” “core features functional in a test build,” or “app passes QA and is submitted to the app stores.” Vague markers like “halfway done” are how payment disputes start. Tying payment to a deliverable protects both sides: the developer gets paid for verifiable progress, and you aren’t paying for time that produced nothing usable.

For a shorter project (roughly 8-12 weeks), a simple three-part split is common: a deposit at signing, a mid-project payment once a working build or design phase is approved, and a larger final payment on delivery. Longer or more complex builds break the middle into three or more milestones, for example discovery/design, backend and core features, integrations, and QA/launch, so no single payment represents too big a jump in risk for either party.

Deposits scale with project size and trust. Small engagements often see a deposit at the higher end of the range, sometimes as much as half, because the dollar amount at risk is low. Larger builds typically use a smaller deposit with more, smaller milestones. It’s also common to see a small final holdback, often a modest slice of the total, kept for a warranty window (commonly 30-90 days) after launch and released once the app has been live and stable. That gives you leverage to get post-launch bugs fixed without withholding the whole final payment.

Sample Developer Schedule: Building an App, Step by Step

Building an app usually moves through the same stages, and the cleanest payment schedules mirror them. Here is an illustrative schedule for a mid-sized project. The percentages are examples to negotiate from, not a rule, and your project may need different splits.

Stage 1, signing and discovery: you sign the contract, pay the deposit, and the developer runs requirements workshops and produces a written scope. Stage 2, design: wireframes and UI designs are delivered; the next payment is released when you approve them in writing. Stage 3, core build: backend and main features are functional in a test build you can actually tap through; payment is tied to that demo. Stage 4, integrations and polish: payments, logins, third-party services, and analytics are connected. Stage 5, QA and submission: bugs are fixed, the app passes testing, and it is submitted to the App Store and Google Play. Stage 6, launch and warranty: the final payment is released at acceptance, minus any holdback that is released after the warranty period.

Ask any developer for a timeline like this before you sign. A written developer schedule with dates, deliverables, and payment triggers side by side is the single best defense against a project that drifts. Also budget for costs that sit outside the developer’s invoice: Apple charges an annual Apple Developer Program membership (listed at $99 per year on Apple’s site at the time of writing), and Google Play has its own one-time registration fee. Decide in the contract whether the developer uses your accounts or theirs; your app should be published under an account you own.

Apple Developer Payment Schedule: When Apple Pays You

Once your app is live and earning money through paid downloads, in-app purchases, or subscriptions, a different payment schedule applies: Apple’s payouts to you. Apple pays on a monthly cycle tied to its fiscal calendar rather than the standard calendar month. Apple’s fiscal months run 28 or 35 days, and payment generally arrives about 33 days after each fiscal month ends. That means revenue from a given sales period typically reaches your bank account more than a month later, and Apple does not publish a single fixed payout date for everyone, so check your own dates in App Store Connect.

To actually get paid you need: an active Paid Applications Agreement, banking information entered in App Store Connect, completed tax forms, and earnings above the minimum monthly payment threshold for each country or region where you sell. Earnings below the threshold roll forward until they cross it. Some regions also require monthly invoicing. For Apple’s exact terms, refer to the Paid Applications Agreement and financial reports inside your account, or start at Apple’s official Developer Program page.

Why this matters when hiring: if your developer is paid from app revenue (a revenue share) instead of fixed invoices, their payment schedule inherits Apple’s lag. Spell out in the contract whether payments are due after Apple pays you or on a fixed calendar, so nobody is surprised by the 30-plus day delay.

Fixed-Price vs. Time-and-Materials Schedules

On a fixed-price contract, the payment schedule is tied to milestones as described above, with the total agreed before work starts. It works best when scope is well defined, such as a clearly specified MVP rather than an evolving product.

On a time-and-materials (T&M) contract, you’re billed for actual hours or sprints, usually invoiced weekly, biweekly, or monthly rather than by milestone. T&M suits ongoing development, agile teams, and projects where requirements will change. Many agencies use a hybrid: fixed price for a defined first phase, then T&M or a retainer for iteration after launch.

Neither model is inherently better. Fixed price gives budget certainty but only if the scope is genuinely fixed; T&M gives flexibility but requires more trust and closer tracking of hours against real progress. With T&M, ask for regular demos and a cap or budget alert so costs can’t quietly balloon.

Tips and Common Mistakes

Never pay 100% upfront, no matter how good the pitch sounds. It removes any leverage to get the work finished. Be equally cautious of a developer who wants everything on delivery with no deposit: a reasonable deposit is standard, and zero upfront payment can signal a rushed or undercapitalized team.

Put the payment schedule and milestone definitions in the written contract. Specify what “complete” means for each milestone, such as “approved by client in writing” instead of “developer says it’s done.” Ambiguous milestones are the most common source of payment disputes.

Watch for scope creep changing the math. If features get added mid-project, revisit the schedule by adding a milestone or adjusting the final payment, and get any change in scope and cost in writing before work continues.

For larger or first-time engagements, consider a milestone escrow service or platform instead of direct bank transfer, so funds are released only when both sides confirm a milestone is met. Finally, confirm what happens to source code and assets if the relationship breaks down: ownership should transfer only after the corresponding payment clears, and you should keep access to your repository, app store accounts, and hosting throughout.

Build It With GTStudios

If you’d like a clear scope, a written timeline, and milestone-based payments you can actually verify, GTStudios can walk you through the plan before any money changes hands.

app development payment schedule FAQs

What percentage should I pay upfront for app development?

There’s no fixed rule, but a deposit somewhere in the 20-50% range is typical. Smaller projects tend toward the higher end, and larger budgets toward the lower end paired with more milestones. Whatever you agree, put it in writing.

Is it normal to pay a developer before the app is finished?

Yes. A deposit and milestone payments before final delivery are standard. What matters is that each payment is tied to a verifiable deliverable and that you never pay the full amount before the work is complete.

What should count as a milestone in a payment schedule?

Anything specific and checkable: approved designs, a working test build with named features, integrations connected, QA passed, or store submission completed. Define each one as approved by you in writing.

Should I hold back part of the final payment after launch?

Often, yes. A small holdback released after a 30-90 day warranty window gives you leverage to get post-launch bugs fixed. Agree the amount and the warranty terms in the contract.

What is the Apple developer payment schedule?

Apple pays App Store developers monthly, generally about 33 days after each Apple fiscal month ends. You need a Paid Applications Agreement, banking and tax details in App Store Connect, and earnings above the minimum payment threshold for each country or region. Check App Store Connect for your exact dates.

How long does it take to build an app, and how does that affect payments?

Simple apps can take a couple of months and complex ones much longer. Longer timelines usually mean more milestones with smaller payments, so the schedule tracks real progress instead of the calendar.

Should I pay a developer hourly or per milestone?

Use milestones on a fixed-price project with a clear scope. Use hourly or sprint billing (time and materials) when requirements will evolve. A hybrid of fixed-price for the MVP and T&M afterward is common.

Build It With GTStudios

Need help with your website, app, or small-business tech? GTStudios builds web, apps, and software for small businesses. See how GTStudios can help.

Want dev news in your inbox? Subscribe to the free newsletter.