How to structure app development payments: deposits, milestones and when the code changes hands

Tie each payment to something you can open

Dates are a poor trigger for payment. Deliverables are better.

A milestone that says "week four" gets paid whether or not anything works. A milestone that says "a test build with login and the booking flow, installed on your phone" gets paid when you have seen it. My rule for every line in a schedule: you should be able to check it yourself, in under an hour, without the developer explaining it to you. If you cannot, the milestone needs rewording.

The deposit is the exception. It pays for work that starts before there is anything to show, such as scoping, setup and the first design drafts, and it books the developer's time. Keep it modest, and make sure the contract says what happens to it if the project stops early.

A worked schedule at $999, $1,699 and $2,500

This is an example structure to ask for, not my own payment terms. It splits each of my package prices into a 20% deposit, 20% on approved designs, two 25% build stages and a final 10%, rounded to whole dollars. Adjust the split to suit you; keep the shape.

When the code should change hands

Two patterns are common. In one, the code lives in the developer's account and is handed over after the final payment. In the other, the repository is in your company's account from the first commit, so the code grows in your hands as you pay for it.

I recommend the second. You can see progress between milestones, nothing has to be transferred at the end, and the final payment is about finishing the work rather than releasing a hostage. My app handover checklist lists everything else you should hold: store accounts, signing keys, hosting, database and service logins.

Ownership of the code is a legal question as well as a technical one. The contract decides when the rights pass to you, and whether the developer keeps any reusable parts. I am not a lawyer and this is not legal advice. Have a lawyer read the ownership clause before you sign.

Questions to settle before you pay the deposit

Send these to your developer with the scope. The answers belong in the contract, not in a chat thread.

• What exactly triggers each payment, in words you can check yourself?
• How many days do you have to test a milestone before it counts as accepted?
• If a milestone fails your check, what is fixed before you pay, and who decides?
• Is the final payment tied to store submission, or to approval? Approval is the stores' decision, not the developer's, so submission plus handover is the fairer trigger.
• How are changes priced, and are they paid with the next milestone or separately?
• What happens to the deposit and the work done if either side stops the project?
• Are invoices in USD or AED, and who pays bank transfer charges? This matters for UAE companies paying a developer abroad, or the reverse.
• Is the repository in your company's account from day one?

Paying for one of my packages

My packages are fixed prices: Launch at $999, Growth at $1,699 and Scale at $2,500, and the exact scope is agreed in writing before work starts. Ask me for the payment schedule along with that written scope, and hold it against the checklist above.

Some work sits outside the package price and would get its own scope and milestones: custom AI systems, complex payment gateways, real-time streaming, hardware integrations, complex ERP modules and specialised compliance work. Custom software such as an ERP or LMS is a fixed quote rather than a package. Third-party fees, hosting and maintenance are not included. If the app is rejected at review, I fix and resubmit at no cost, though approval stays with the stores. For what each package costs in AED and what changes the price, see my UAE app cost page.