App Project Payment Schemes: Down Payments, Milestones, and Who Really Owns the Code

In almost every initial conversation about an app project, two topics always come up before we even discuss features: how much of a down payment is required, and whether the source code will ultimately belong to the client. Both topics sound administrative, yet that's exactly where disputes most often arise — not because one party has bad intentions, but because expectations were never written down clearly from the start. In this article, I summarize my experience handling projects from the vendor's side: the payment schemes commonly used, what a reasonable software project down payment looks like, and the code ownership issue that is so often left hanging.

Why payments and code often become sources of dispute

In my experience, disputes between clients and app vendors almost always stem from the same two fears. Clients are afraid of paying a lot upfront and then not receiving what was promised — understandable, since app code can't be seen and touched the way a physical product can. Vendors, on the other hand, are afraid of working first without any guarantee of getting paid. If these two fears aren't acknowledged and addressed from the outset, both sides will end up blaming each other mid-project.

The classic dispute goes like this: the client feels they've paid half, so they're entitled to everything, while the vendor feels the work already done hasn't been properly compensated. Yet all of this can be prevented with one simple thing: an app development contract that explicitly spells out the payment scheme and code ownership, not just the scope and timeline.

The common payment scheme: down payment, milestone-based installments, final payment

The scheme I use most often — and encounter most frequently — consists of three parts:

• Down payment when the contract is signed, to cover the initial work: requirements analysis, UI design, and technical setup.
• Milestone-based installments, meaning staged payments triggered by the completion of a specific part of the project — for example, after the design is approved, after the core module can be tested, or after the beta version is ready.
• Final payment at handover, after the app is released and all handover materials are delivered.

This structure is fair because it protects both parties at once. The down payment gives the vendor certainty to start working; the installments give the client control, since you're not paying in full for something whose results you haven't seen yet. What I avoid are the two extremes: a vendor demanding full payment upfront, or a client refusing any down payment and wanting to pay everything only after the app is finished. Both are signs of an unhealthy scheme.

What a fair down payment looks like, and when installments should be tied to results

The question "how much of a down payment is fair" has no single answer, but there's a reasonable pattern. For small to medium-scale apps, a down payment in the 30–50 percent range is fairly common, because the initial work — analysis and design — absorbs a significant amount of effort. Larger projects usually have a proportionally smaller down payment, with more numerous and more detailed installments.

Far more important than the number is tying each installment to a clearly defined result. Avoid installments defined purely by time, such as "the second installment is paid in the second month." Replace them with verifiable outcomes: "the second installment is paid once the registration and payment modules can be tested in the staging environment." That way, if a disagreement arises, the reference point is the work itself — not an interpretation of the calendar. This principle also makes app vendor payment milestones feel fairer to both parties.

The rule of thumb I hold to: every payment should be paired with a result you can see, run, and test yourself — not just a promise in a presentation deck.

Code ownership: full handover vs. renting a subscription system

This is the part that most often triggers misunderstandings, because there are two equally legitimate business models — and you need to know from the start which one you're buying.

The first model is a custom project with full handover. You pay for the development, and at the end of the project the source code, documentation, and rights to the work product transfer to you. This model suits situations where the app is a core business asset and you want the freedom to switch vendors or hire in-house developers in the future.

The second model is a subscription system. The vendor builds and operates the system, you pay monthly or annually, and the code remains the vendor's property. This model is legitimate and often lighter at the start, but the consequence is clear: if the subscription ends, access to the system may end with it.

Neither model is wrong. What's dangerous is the ambiguity. Ask three things before signing: am I buying the code or renting the system; if buying, what exactly is handed over at handover; if renting, what happens to my data after the subscription ends.

Checklist before signing — and how I work

Before signing an app development contract, check the following five things:

1. A written contract that explicitly includes the scope of work, timeline, payment scheme, and code ownership clauses.
2. Access to the source code repository — ideally you can see code progress from the start, at minimum at handover.
3. Technical documentation and admin guides, not just the finished app.
4. Critical accounts registered in your name: domain, server or hosting, App Store and Play Store developer accounts, and any third-party services the app uses.
5. A post-handover agreement: who maintains the app, what the maintenance costs are, and what happens if the engagement ends.

The fourth point is often underestimated despite being the most crucial — if the domain and server are registered under the vendor's name, in practice you're merely renting your own assets.

As for how I work: the payment scheme is explained from the proposal stage, every installment is tied to a testable milestone, and the source code along with its documentation is handed over without drama when the project is complete. I've written out the full flow openly on my work process page, and if anything remains unanswered, it's usually covered in my list of frequently asked questions.

In the end, a healthy payment scheme is one that makes both parties confident enough to start, and clear code ownership is what keeps you from depending on a single vendor forever. If you're planning an app and want to discuss a payment scheme or code ownership arrangement that makes sense for your case, tell me about your needs through the contact page — let's dig into it before any numbers or contracts are signed.