Most studios obsess over the quote. We polish the scope, we itemise the deliverables, we add a clause about change requests, and then we send it off and wait for a signature. But the document that actually governs the relationship is not the quote. It is the schedule of payments underneath it. The way money moves through a project quietly decides how a client treats you, how much risk you carry at any moment, and whether a stalled project becomes a stalled cashflow. If you want to change one thing about how your studio runs, start with when and how you get paid, because that structure does more work than any paragraph of prose.
The deposit is not a formality, it is a filter
A deposit does two jobs, and only one of them is about money. The obvious one is that it funds the start of work and proves the client is solvent. The quieter one is that it filters out people who were never going to proceed. A prospect who happily signs a quote but goes silent the moment a 40% deposit invoice lands was always a risk, and you want to discover that in week zero rather than week three. The deposit is the cheapest, fastest signal you will ever get about whether this project is real.
The common mistake is treating the deposit as an admin step you can collect later, once the client is 'warmed up'. So you start sketching, you join a kickoff call, you set up a repo, and three weeks in you are fifteen hours deep with no money received and a client who now feels entitled to your time. Flip it. Nothing happens before the deposit clears. Not a Figma file, not a call longer than the scoping conversation you already did for free. This is not harsh; it is the thing that lets you say yes to work without betting your month on a stranger's follow-through.
Size the deposit to the risk, not to a habit. For a new client with no track record, 40 to 50% upfront is reasonable and signals seriousness. For a returning client who has always paid on time, you can afford to drop it. The number is a lever you adjust per relationship, not a fixed ritual you apply to everyone identically.
Tie milestones to things the client can see, not things you do
The temptation with milestone payments is to bill against your internal process: payment on 'backend complete', payment on 'integration done'. The problem is that none of those mean anything to the client, which means every milestone invoice becomes a negotiation about whether the thing is really done. 'Backend complete' is invisible. The client cannot look at it, so they have no basis to agree you have earned the payment, and you end up demonstrating progress twice.
Instead, anchor each milestone to a demonstrable, client-visible outcome. 'The client can log in and see their own dashboard.' 'The client can place a test order end to end on a staging link.' These are moments the client can verify themselves in two minutes. When the milestone is self-evident, the invoice feels earned and the payment clears without a meeting. As a bonus, defining milestones this way forces you to slice the work into vertical, shippable chunks rather than horizontal layers, which is better engineering practice anyway.
Keep the number of milestones low. A three-week project does not need five payment points; two or three is plenty. Every milestone is an invoice, a follow-up, and a potential point of friction, so each one needs to carry real weight. For longer builds, a time-boxed cadence can work better than feature-based milestones: a fixed amount every two weeks regardless of exact progress, which smooths your cashflow and removes the 'is it done enough to bill' argument entirely. Choose the model that matches whether the risk lives in scope or in duration.
The final payment is where projects go to die
The most dangerous money in any project is the last slice, because by the time you are owed it, you have already delivered almost everything. Your leverage is at its lowest exactly when the amount outstanding is still significant. A client who has their working product and owes you 30% has very little pressure to pay quickly, and 'we will settle up once we have reviewed everything' can stretch for weeks while you chase an invoice for work that is finished and in use.
Protect yourself structurally rather than relying on goodwill. Keep the final payment small enough that it is not worth anyone's while to withhold, which means loading more into the deposit and milestones. Make the trigger for the final invoice something crisp and dated, such as 'handover of production credentials' or 'the day we deploy to your domain', and send that invoice before the trigger event, not after. A deployment held pending final payment is a legitimate and quietly effective position, far better than deploying first and then asking nicely.
Watch for the slow-review trap, where a client stretches an acceptance period to defer payment. Define acceptance explicitly in the quote: the client has, say, five working days to raise defects against the agreed scope, after which the milestone is deemed accepted and the invoice is due. Without that clause, 'we are still testing' becomes an open-ended excuse, and the burden of proving completion stays with you indefinitely.
What to put in writing before anyone starts
Spell out the whole payment schedule in the quote itself, with amounts and triggers, not just a total. 'R60 000, split as R24 000 on acceptance of this quote, R18 000 when staging is available for review, R18 000 on deployment to production' tells the client exactly how the money and the work move together. Vagueness here always costs you later, because the client fills the gaps with the interpretation most favourable to them.
Add payment terms that are specific and short. 'Payment due within seven days of invoice' with a stated consequence for late payment is more useful than the polite silence most studios leave. You will rarely need to enforce the consequence, but its presence changes behaviour. Equally, state what happens if the project pauses on the client's side: work resumes only once outstanding milestones are settled, so a client cannot park a project indefinitely while you carry the exposure.
The takeaway
On Monday, go back to your current quote template and separate the money from the words. Write an explicit payment schedule with named amounts and client-visible triggers, and put it in every quote from now on. Set a firm rule that no work starts until the deposit clears, and size that deposit to the client's track record rather than habit. Rewrite your milestones so each one is something the client can verify in two minutes, and keep them to two or three per project. Shrink your final payment so it is never worth withholding, tie its invoice to deployment, and send it before you deploy rather than after. Add a short acceptance window with a clear default to accepted, and specific payment terms with a stated consequence for lateness. None of this is about distrust; it is about building a structure where paying you is the path of least resistance, so you can spend your energy on the work instead of chasing invoices for work already done.