Milestone payments in software development: how paying by stage protects you

What milestone payments are, and what they are not

A milestone payment schedule splits the project price into parts tied to stages of the work. Instead of paying everything up front, or paying monthly invoices for hours, you pay as the product takes shape.

The common alternatives look like this:

• 100% up front. Simple for the vendor, all risk on you.
• Time and materials. You pay for hours each month. Flexible, but the total isn’t fixed, and you pay for effort, not results.
• Payment on completion. All risk on the vendor, so it rarely works beyond a small job: the vendor finances the whole project and prices that in.
• Milestones. The price is fixed and split into stages. Done well, risk is shared in proportion to delivered work.

The phrase that matters in the last line is “delivered work”. A schedule that says “30% at start, 40% in the middle, 30% at the end” is milestone payments in name only. Nothing ties the middle payment to anything you can check.

The three things that make stage payments protective

1. Each milestone is a deliverable, not a date or an effort

“Development, 40%” is a black box. “User accounts and profiles: sign-up by email and Google, profile editing, password reset, admin view of users” is a milestone. You can open it, try it, and say yes or no.

Good milestones are defined by modules of the product, each with a description precise enough to test.

2. Each milestone has an acceptance rule

You need to know:

• how the work is delivered for review (a test build, a link, a branch);
• how long you have to review it;
• what counts as a reason to send it back;
• what happens if you say nothing.

Without this, “acceptance” becomes a negotiation every time.

3. The money follows acceptance

The strongest arrangement is that money you have paid is not considered earned until you accept the work it pays for. Then a payment is not a bet on future work. It sits in reserve until the module it covers is done and checked.

How it works at EVA-X

We run every project on this model, so here are the specifics, as our terms set them out.

• The contract is signed online. It fixes the price, splits the scope into modules and sets a payment schedule: in full or by stages.
• The first payment is due before work starts, and the timeline runs from the day it arrives.
• Payments go into the project reserve. They are applied to the price of a module only when you accept that module. The cabinet shows how much you have paid, how much has been released for accepted modules and how much is held.
• Each module comes with 7 calendar days for review. You accept it, or send it back with a reasoned list of specific non-conformities, each described so it can be reproduced. Fixes that bring the module in line with the agreed scope are free.
• If you stay silent for the whole review period, or start using the module in production, it counts as accepted. That is standard and fair, but worth knowing in advance.
• Refunds come from the unspent part of the reserve. If a project ends early, the work done on modules still in progress is paid for and handed over, costs you approved that can’t be recovered are deducted, and the rest is returned.

One honest clarification: the project reserve is our accounting of prepayments not yet earned. It is not an escrow, trust, deposit or segregated account, and no third party holds it. What it gives you is a contract rule that money is earned only on acceptance, and a cabinet where you can see where every payment stands.

How to keep track during the project

Even with good terms, keep your own simple record. For every payment, note which module it covers, when the module was delivered, when you accepted it or sent it back, and what is still held. Before paying the next invoice, check that the record matches what the vendor shows you. It takes ten minutes a month and turns any later disagreement into a comparison of two tables instead of two memories.

If several people on your side follow the project, agree who accepts modules. Acceptance has legal weight — under our terms it works as a signed certificate of acceptance — and the money for that module is released to the vendor. It is better done by one responsible person than by whoever opens the email first.

Common payment structures compared

What to check in any milestone contract

Before you sign, go through the contract with these questions:

• Is each stage a module with a description, or a percentage of a phase?
• What is the review period, and what happens when it ends?
• What is a free revision, and what is a change request? Fixing what doesn’t match the agreed scope should be free. New wishes have their own price. The contract should draw that line.
• What happens to prepaid money if the project stops? Who pays for work in progress, and how is it calculated?
• When do the rights to the code pass to you? Usually on full payment, sometimes module by module as each is paid. See who owns the code.
• How long do you have to pay an invoice, and what happens if you’re late? Work may pause; know the terms.
• What warranty comes with accepted work? For example, how long the vendor fixes reproducible defects free of charge after acceptance.

Traps that look like protection

A small first payment, a huge last one. This feels safe until you realise the vendor has been financing the work and has every reason to cut corners or stall to protect itself. Balanced risk keeps both sides working.

Acceptance tied to “launch”. If the final payment waits for a launch that depends on your marketing, your content or your app store account, the vendor can’t influence it, and disputes follow.

Milestones that can’t be tested alone. “Backend complete” can’t be checked by a client without a front end. Group work into modules a person can use.

Paying for percentage complete. “The project is 60% done” is an opinion. A module is either accepted or it isn’t.

No word on change requests. Without a clear process, every new idea mid-project becomes an argument about whether it was “already included”.

What a payment schedule can’t fix

Stage payments limit how much money is at risk. They don’t make a project go well on their own.

• A vague scope. If the contract describes a module as “user management”, acceptance will turn into an argument about what that includes. The time to be precise is before signing. Our guide on writing a brief a studio can price helps here.
• Slow decisions on your side. If nobody can review a delivery for three weeks, the schedule doesn’t help; the project simply stands still. Name one person who decides and answers questions.
• The wrong vendor. A good schedule with a weak team still gets you a weak product, just in smaller pieces. Look at their delivered work, not only their terms.
• No test data or access. If reviewing a module needs your real products, texts or access to a payment provider, prepare them in advance. Otherwise the review period runs out with nothing to check.

How stage payments protect the vendor too

A schedule that only protects one side doesn’t hold. A vendor who isn’t sure they’ll be paid for finished work will pad estimates, slow down or stop answering. Balanced terms keep a good team on your project:

• the first payment covers the start of the work;
• a review period with deemed acceptance stops a module from sitting unreviewed for months;
• clear change requests stop the scope growing for free;
• payments released on acceptance mean the vendor is paid reliably for work that passes.

When you read a vendor’s terms, those clauses are not red flags. They are what makes it possible for them to fix the price at all.

An example of a well-built schedule

For a hypothetical booking app with a web admin, a module-based schedule might look like this:

1. Accounts and profiles: sign-up, sign-in, profile, password reset.
2. Catalogue and search: services, filters, detail pages.
3. Booking and payments: calendar, checkout, receipts, refunds.
4. Admin: managing services, bookings and users, basic reports.
5. Release: store builds, store listings, production setup.

Each module can be opened and tried by a non-engineer. Each has its own price in the contract, so you always know what a payment buys. The modules won’t cost the same: booking and payments carry more logic and more edge cases than profiles, so they take a larger share of the price. That’s normal, and it’s another reason to tie payments to modules rather than to equal slices of time.

If you’re comparing contract models, read fixed price vs time and materials and our guide to software acceptance criteria. To see how your own product would split into modules, with a timeline and a fixed price, describe it on the estimate, or read about our custom software development.