Stop Paying 50% Upfront: 5 Smart Milestone Rules

A founder I spoke to last month wired $14,000 to a development shop on a Friday.

By Tuesday, the lead developer they had been promised was quietly on another project.

By week six, the build was 30% done and 70% of the budget was gone.

She had paid half the contract upfront. She had no acceptance criteria written down. She had no way to pause payments without burning the whole project.

This is the most expensive mistake a non-technical founder can make, and it has nothing to do with code.

It has everything to do with how the contract pays out.

The take

Never pay more than 20-30% of a software contract upfront.

Never pay the final 20-30% until you have signed off, in writing, on a working build.

Tie every dollar in between to a specific, testable deliverable, not a calendar date.

That's it. That's the whole game.

If a vendor pushes back on this, you have your answer about whether to work with them.

Why this matters more than the hourly rate

Founders obsess over hourly rates. 40/hour vs 80/hour vs $150/hour.

The hourly rate is a distraction.

The real risk is structural. A contractor with 50% of your money already in the bank has very different incentives than one waiting on the next milestone. When you outsource custom software development, you face a fundamental challenge: how do you pay a vendor fairly while protecting your business from incomplete work, cost overruns, or outright project failure? Milestone-based payment structures create accountability at every stage of development and align the vendor's financial incentives with your project goals.

Translation: the right payment structure does more to protect your money than any clause about quality, any reference check, or any contract template you found online.

The 20/30/50 structure (and when to flex it)

The classic milestone split is 20% upon signing, 30% at midway, and 50% upon completion.

That works for short builds (8-12 weeks).

For longer builds, break the middle 30% into two or three milestones. A common 2026 structure looks like this:

Milestone-based payments balance risk for both parties. Typical structure: 20-30% upfront deposit (shows client commitment), 40-50% in 2-3 milestone payments (tied to completed features), 20-30% upon final delivery and acceptance. Avoid: 100% upfront (gives developer no incentive to finish), 100% at end (developer assumes all financial risk), hourly with no cap (creates budget uncertainty).

The retention idea is underused but smart. Many businesses include a retention provision, holding back 5-10% of the total contract value until a specified warranty period expires, often 30 to 90 days after final delivery. This retention amount incentivizes the vendor to address post-deployment bugs and ensures they remain engaged during the critical early operation period.

You launch. Bugs show up. The vendor has 5-10% of the contract still on the table. They fix them quickly.

If you skip retention, you get to chase them via email for six weeks while your users churn.

5 contract rules that actually stop the bleed

This is the part most founders skip. Don't.

1. Each milestone has acceptance criteria, in writing, before work starts

"Phase 1 complete" is not a milestone. It's a future argument.

A real milestone looks like this: "User authentication module, supporting email + Google login, deployed to staging URL, passing the 12 test cases listed in Appendix A, reviewed and signed off by [founder] within 5 business days."

The effectiveness of milestone-based payments depends entirely on how you define the milestones themselves. Vague milestones like "substantial progress on backend development" create disputes. Clear milestones tied to objective criteria prevent ambiguity and make enforcement straightforward. Effective milestone definitions typically include three components: a specific deliverable, acceptance criteria, and a deadline.

If the vendor can't write the acceptance criteria, they don't understand the work. That's a red flag, not an inconvenience.

2. Set a review window and a "deemed accepted" clause

You need a fixed window to review and accept each milestone. Add a clear review window in the contract (commonly 5 business days). Within that window, the client accepts or raises issues. If there's no response, the milestone is treated as accepted.

5-15 days is normal, depending on complexity.

The "deemed accepted" rule protects the vendor too. It stops you from ghosting them and stops them from chasing you for payment.

3. Define what happens when a milestone misses

Most contracts skip this and pretend everything will go fine.

It won't.

Spell out: how long is the cure period? What if it misses again? Does the contract pause? Can you terminate without losing the work done to date? Who keeps the source code if it ends badly?

Both parties need termination rights: 'Termination for Cause' (either party can terminate immediately if other breaches contract, non-payment, missed deadlines, quality issues, with 7-14 day cure period), 'Termination for Convenience' (client can terminate anytime with 30-day notice, pays for work completed plus termination fee of 10-25% of remaining contract). Upon termination: client receives all work completed to date, source code, documentation.

If you don't have a clean termination clause with source code transfer, you can lose your software.

4. Tie payments to deliverables, not dates

This is the single most important rule.

If your contract says "pay 30% on June 15," you'll pay 30% on June 15 whether anything has shipped or not.

If your contract says "pay 30% when [named feature] is deployed to staging and accepted," you only pay when work has actually moved.

Calendar deadlines are useful as targets. They should never be the trigger for payment.

5. Write a change order process before you need one

Halfway through the build, you'll want to add a feature. Or the vendor will discover something the discovery doc missed.

Contract must define: 1) What constitutes a change (vs bug fix or included work), 2) Change request process (written request, developer provides time/cost estimate, client approves before work starts), 3) Pricing for changes (hourly rate, typically 10-20% premium over base rate), 4) Timeline impact (changes extend delivery dates), 5) Minor changes policy (small tweaks under 2 hours might be included). Without clear change process, expect disputes and budget overruns.

The most expensive change orders are the ones nobody documented. Six weeks later, nobody remembers what was agreed, and you're arguing over a $12,000 invoice.

When milestone payments are the wrong call

A few cases where this advice flexes.

Very short engagements. If the whole job is two weeks and $4,000, milestones add overhead that costs more than it saves. A 50/50 split is fine.

Pure staff augmentation. If you're embedding a developer into your team for ongoing work, you're paying for time, not deliverables. Weekly or biweekly invoicing makes more sense.

Trust-tested long-term relationships. Once you've worked with a vendor for a year and they've never missed, you can move to looser payment terms. Earn the trust first, then loosen the contract.

For everything else (a defined-scope build, a fixed budget, a non-technical founder, a vendor you haven't worked with before), milestones are your insurance policy.

The artifact: 7 questions to ask your vendor before signing

Copy this. Send it to whoever sent you the contract.

1. What percentage do you require upfront, and what triggers each subsequent payment? If they say more than 30% upfront, push back.

2. Can you write out the acceptance criteria for each milestone before we sign? If they hesitate, they don't know the work.

3. What's the review window, and what happens if I miss it? You want a clear "deemed accepted" rule.

4. What happens if a milestone misses the deadline? You want a defined cure period.

5. If we end the contract, do I get the source code, designs, and all work to date? The answer must be yes, with IP assigned to you.

6. What's your change order process and pricing? You want this in writing before signing.

7. Is there a warranty period after launch, and do you hold back any payment to cover it? A 5-10% holdback for 30-60 days is healthy.

If they answer all seven cleanly, you're working with a real team. If they get defensive on any of them, you've learned something valuable for the price of an email.

A word on what we do

At Apptage, we've shipped 100+ apps and 500+ web portals in the last four years. Every one of them ran on a milestone contract with clear acceptance criteria, a defined review window, and source code rights that transfer to the client from day one. We work this way because we've seen what happens when builders don't.

If you've got a contract on your desk and you're not sure if it protects you, send it over. We'll read it and flag what's missing, no strings attached. Or if you're earlier than that, you can book a 20-minute scoping call and we'll talk through your build before you sign anything.

Our MVP development process is built around exactly this structure. You can see how it played out for a real product in the Caribo case study, where staged milestones let the founder course-correct twice without blowing the budget.

P.S. The single most expensive mistake we see is founders who pay 50% upfront because the vendor offered a "discount" for it. The discount is almost always smaller than the rework cost when the project drifts. Don't trade your leverage for 5% off.

P.P.S. If the contract on your desk has the words "best efforts" anywhere near a payment clause, that's the part to red-pen first. "Best efforts" is the legal version of "trust me."