Commercial guide for developers
Developer deposit structures that protect the start of a project
Choose a deposit and milestone structure that funds project kickoff, makes approval points visible, and keeps final payment connected to handover.
A deposit should do more than reserve time. It should define when the engagement becomes active, what the developer can begin, and how the remaining project value becomes payable.
01
Define what the deposit activates
State that work begins after both the agreement is signed and the deposit is received. This prevents an accepted proposal from being mistaken for an instruction to start before the commercial terms are complete.
Connect the deposit to concrete kickoff work: technical discovery, environment setup, architecture, sprint planning, or the first agreed build stage.
- —The exact amount and currency
- —The payment deadline
- —The work that begins after payment
- —What happens if the client delays required access or materials
02
Choose a structure that matches delivery risk
A short, well-defined engagement may use a larger deposit and one final payment. A longer build normally benefits from smaller payments tied to reviewable stages. Percentages are useful only when the events behind them are clear.
- —50 / 50: suitable for a short build with one clear acceptance point
- —30 / 40 / 30: useful for deposit, staging approval, and production handover
- —Deposit plus monthly milestones: useful when delivery spans several months
Example structure
30% after signature, 40% after the agreed staging build is approved, and 30% before production handover and transfer of final access.
03
Do not leave too much value at final handover
A small deposit followed by a very large final invoice leaves the developer financing most of the project. Break the work into stages the client can inspect, and invoice while the value of each stage is visible.
Define handover precisely. Source-code access, deployment credentials, documentation, training, and intellectual-property transfer may happen at different points and should not be treated as one vague final step.
04
Keep new scope out of the original price
The deposit funds the agreed scope; it does not create an unlimited development allowance. Require a written change order when a new feature, integration, role, platform, or material acceptance change affects cost or delivery time.
Put this into the agreement
A practical final check
- 01Name the deposit amount, currency, and due date.
- 02Make signature and cleared deposit the start condition.
- 03Tie later invoices to observable build or approval events.
- 04Define exactly what final handover includes.
- 05Route additional features through a signed change order.
Editorial standard
Written from the workflow the product actually supports.
- Prepared by
- The Censiq product team, which designs and maintains the agreement, invoicing, retainer, and reminder workflows described in this guide.
- Review method
- Product-specific statements were checked against the current Censiq workflow. No customer outcome, legal result, or payment-speed claim is inferred.
- Dates
- Published August 13, 2026. Last reviewed August 17, 2026.
- Corrections
- Found something inaccurate? Email support@getcensiq.com.
Continue with a related guide
All independent professionals
Milestone billing based on events a client can recognize
Read guideProduct designers
Design revision clauses that keep feedback inside the agreed scope
Read guideGeneral operational information only. This guide is not a substitute for legal, tax, or financial advice.