The work is won.
Now make sure you get paid and stay protected.

Purpose & audience

Most software people can build. Far fewer were ever taught the disciplines that decide whether the building actually pays.

The companion guides in this library take a project from a vague idea, through a defensible estimate, to a signed deal. This one picks up at the signature and covers everything that determines whether that signature turns into money in your account: how you structure the payments, what the contract says when a disagreement arises, who owns the code, how you invoice, and what you do when a client stops paying.

It is written for independent developers, small software firms, and anyone selling custom development or a software product who has felt the particular dread of finished work and an unpaid invoice. Everything here is generic and reusable — no company or product specifics — and applies whether you build for Windows, the web, or mobile, and whether you are delivering a brand-new application or enhancing a system that has been in production for twenty years.

The core principle

The companion delivery guide argues that you cannot accurately price what you have not defined. This guide extends that thesis one step: the contract is where the definition gets enforced, and the payment schedule is where it gets funded.

Two failure modes recur throughout. The first is doing the work before securing the money — starting on a promise, delivering everything, and only then discovering how motivated the client is to pay. The second is treating the contract as a formality — signing whatever is put in front of you, or working from a handshake, and then having no leverage when the relationship sours. Almost every section below is an antidote to one of those two mistakes.

A note on law & jurisdiction

With that said, the underlying principles — take a deposit, tie money to progress, define acceptance, cap your liability, keep leverage until you are paid — travel well across jurisdictions. Adapt the specifics; keep the principles.

How you schedule payment matters more than the total. A fair price on bad terms will still hurt you; a fair price on good terms protects both sides.

Never start on zero: the deposit

The single most effective protection in this entire guide is also the simplest: take a deposit before you write a line of code. A client who will not put money down before work begins is telling you something important about how the final invoice will go. The deposit is not just cash flow — it is a filter for commitment and a test of whether the client actually has budget.

Common structures for fixed-scope work are a third up front, a third at an agreed midpoint, and a third on acceptance; or half up front and half on delivery. The right split depends on project length and your cash-flow needs, but the principle is fixed: the money in your account should always be at least even with, and ideally ahead of, the value you have delivered. If you are ever in a position where you have delivered more than you have been paid for, you have handed the client your leverage.

For a paid discovery phase (strongly recommended in the delivery guide as an alternative to quoting blind), the discovery fee is the deposit for that phase, and it is billed and collected before discovery begins. Discovery that has not been paid for is unpaid overhead.

Milestone vs. time-and-materials

There are two honest ways to bill software work, and they protect you differently.

Whichever you choose, write it into the contract explicitly, and pair it with a change-control clause (see 02). The most expensive projects are the ones billed fixed-price against a scope that was never actually fixed.

Payment terms & late fees

Payment terms define when an invoice is due. “Net 30” means payment is due thirty days after the invoice date; “due on receipt” means immediately. Shorter terms are better for you, and there is no rule that says software vendors must offer Net 30 — for a small firm, Net 14 or due-on-receipt on milestone invoices is entirely reasonable, and worth stating up front so it is never a surprise.

A late-payment clause gives the terms teeth. It typically specifies interest on overdue amounts (often expressed as a monthly percentage) and may allow you to suspend work while an invoice is outstanding. Two cautions: many jurisdictions cap the interest rate you may lawfully charge, and an unreasonable rate can be unenforceable — so set it within legal limits for your area. And a late fee is a deterrent, not a business model; the goal is to be paid on time, not to profit from delay.

Retainers & recurring revenue

Project revenue is lumpy; retainers smooth it. A retainer is a recurring fee — monthly is common — in exchange for an agreed block of availability, hours, or a defined support scope. It converts the feast-and-famine of one-off projects into something you can plan around, and it is the natural bridge from delivery work into the ongoing support and maintenance income covered in a later guide.

Retainers are typically billed in advance for the coming period — you are paid at the start of the month for the availability you are reserving, not at the end for hours already spent. Be explicit about what unused hours do (do they roll over, and for how long?) and what happens when a month's work exceeds the retainer (billed at an agreed overage rate). Vague retainers become arguments; specific ones become dependable revenue.

A contract is not there for the projects that go well. It is there for the one that goes wrong — and you cannot write it after the trouble starts.

The document stack: NDA, MSA, SOW

Commercial software relationships are usually governed by a small stack of documents, each doing a distinct job. Understanding the split lets you negotiate the stable terms once and the project terms per engagement.

The advantage of this structure is leverage and speed: you negotiate the hard legal terms once in the MSA, then each new project is a short SOW that inherits them. For a small engagement you may fold everything into a single combined agreement — that is fine — but keep the mental separation between durable terms and this-project terms, because that is exactly the seam along which disputes tend to open.

The clauses that actually matter

You do not need to become a lawyer, but you should be able to read a contract and know whether these load-bearing clauses are present and sane. When one is missing or lopsided, that is the moment to push back or get advice.

Termination & the kill fee

Every engagement should say how it can end. Two flavours matter. Termination for cause lets a side exit if the other materially breaches (for example, the client stops paying, or you stop delivering) and fails to cure it within a notice period. Termination for convenience lets a side walk away for any reason with notice — clients often want this, and it is reasonable to grant, provided you are protected on the way out.

That protection is the kill fee: the clause specifying what you are owed if the client terminates for convenience mid-project. At minimum you should be paid for all work completed and in progress up to the termination date, plus any non-refundable costs you have committed. Without it, a client can cancel a fixed-price project when it is 80% done and try to pay for 50%. Spell out that on termination, all work performed to date becomes immediately payable — and remember that ownership of that work still should not transfer until it is paid for.

Your leverage until final payment is that you still own what you built. Your long-term value is the toolkit you carry from project to project. Both live or die in the IP clause.

Who owns the code?

By default, the answer varies by jurisdiction and by whether you are an employee or an independent contractor — which is exactly why it must be stated explicitly rather than assumed. There are two common mechanisms. Under a work-made-for-hire arrangement, the client owns the deliverables from creation. Under an assignment, you own the work first and then transfer ownership to the client. For custom client work, an assignment is usually cleaner and more portable across jurisdictions than relying on work-for-hire doctrine.

Carving out your pre-existing tools

Over years of work you accumulate a toolkit: libraries, frameworks, utility code, boilerplate, design patterns, and internal components you reuse on every job. If a client contract assigns them “all deliverables” without qualification, you may be signing away the right to reuse your own accumulated tools — or even to keep using them yourself.

The fix is a background-IP carve-out: a clause stating that any pre-existing materials, tools, libraries, and know-how you bring to the project remain yours, and that you grant the client a license to use them as embedded in the deliverables — not ownership of the tools themselves. This lets the client use what you built while you keep the reusable machinery that lets you build the next one efficiently. Losing this quietly is one of the most expensive mistakes a productive developer can make, because it compounds: every tool you sign away is one you have to rebuild or relicense forever after.

Open-source obligations

Almost all modern software incorporates open-source components, and each carries a license with obligations — attribution, sharing of modifications, or in some cases requirements that can affect how the surrounding software may be distributed. When you assign deliverables to a client, you are also handing them those obligations, so you need to know what is in the box.

Keep an inventory of the third-party and open-source components in each deliverable and their licenses, and make sure your contract's IP warranties do not promise the client clean, unencumbered ownership of code that in fact contains components under their own licenses. Promising a client you own 100% of something that includes third-party open-source is a warranty you cannot honour. Disclose the components, respect their licenses, and do not warrant away what is not yours to warrant.

Source-code escrow

Enterprise clients buying custom or hosted software sometimes worry about a legitimate risk: what happens to them if your business disappears? Source-code escrow answers it. A neutral third-party agent holds a copy of the source code and releases it to the client only if defined trigger events occur — typically your insolvency or a sustained failure to support the software.

Framed well, escrow is not a concession; it is a sales enabler that de-risks the purchase and can unblock a deal a nervous enterprise buyer would otherwise walk away from. The key is to negotiate narrow, specific release triggers so the client cannot obtain your source code simply because they are unhappy — only in the genuine continuity scenarios escrow exists to cover.

Three clauses decide when the client must pay, when your free-fix obligation ends, and how much a bad day can ever cost you. Get them right and most disputes never start.

Defining “done”

The most draining dispute in software is not about money directly — it is about whether the work is finished. Without objective acceptance criteria, “done” becomes a matter of the client's mood, and a milestone payment can be held hostage to an endless series of “just one more thing” requests that are really new scope in disguise.

The remedy is an acceptance clause with three parts: objective, testable criteria agreed in advance (ideally traceable back to the requirements from the delivery guide); a defined review window (for example, the client has a set number of business days to test against those criteria); and — critically — a deemed-acceptance provision stating that if the client does not respond within the window, the deliverable is considered accepted and becomes payable. That last part is what stops a silent client from freezing a milestone indefinitely.

Warranty vs. paid support

These two are constantly confused, and the confusion costs money. A warranty is a bounded, free promise: for a defined period after acceptance, you will fix genuine defects — the software failing to do what the accepted specification said it would — at no charge. Support is a paid, ongoing service: help, changes, enhancements, environment updates, and everything that is not a defect in the original delivered scope.

Draw the line explicitly, or clients will route every new request through the warranty as a “bug” and expect it free. A warranty should be time-boxed (it ends), scope-boxed (it covers defects against the accepted spec, not new wishes), and condition-boxed (it does not cover problems caused by the client's own changes to the code or environment). Everything beyond that boundary is support — which is a business, not an obligation, and the natural on-ramp to the recurring revenue discussed earlier.

The liability cap

Software touches things that matter — data, money, operations — and if something goes badly wrong, the theoretical damages can dwarf the fee you were paid. The limitation of liability clause is what keeps a modest project from turning into an existential threat to your business. It typically does two things: caps your total liability at a defined amount (commonly the total fees paid under the engagement), and excludes indirect or consequential damages — the client's lost profits, lost business, or downstream losses.

A good invoice removes every excuse for delay. A good chase sequence removes the awkwardness — because the steps are decided in advance, not improvised in a moment of frustration.

Anatomy of an unarguable invoice

Many late payments are not refusals — they are friction. An invoice that is unclear, misdirected, or missing a detail the client's finance team requires simply sits in a queue. Your job is to remove every reason it could stall. A clean invoice includes: a unique invoice number and date; the exact legal names of both parties; a clear reference to the SOW or milestone being billed; a plain description of what was delivered; the amount, any tax, and the total; the payment terms and due date stated explicitly; and complete, correct payment details.

Two practical points remove most friction. First, ask before your first invoice how the client's accounts-payable process works — do they need a purchase-order number, a specific email address, a portal submission? Sending an invoice to the wrong place is the most common self-inflicted delay. Second, state the due date as an actual calendar date, not just “Net 14”; a date is harder to misread and harder to ignore.

Cadence: invoice early, invoice often

Invoice as close as possible to the moment value is delivered, while the client's satisfaction is high and the work is fresh. Do not batch a quarter's work into one large end-of-project invoice — it maximises both the client's payment pain and your exposure. Tie invoices to milestones and send each one the moment its milestone is accepted. On time-and-materials work, invoice on a short, regular cycle (weekly or fortnightly is common for active engagements) so no single invoice ever grows large enough to be frightening, and so a payment problem surfaces early, while little work is at risk, rather than late, when a lot is.

The chase sequence

The reason chasing feels uncomfortable is that people improvise it under stress. The fix is to decide the whole sequence in advance, so that following up is just executing a plan — polite, escalating, and consistent. This mirrors the after-the-demo follow-up discipline from the sales playbook, applied now to accounts receivable.

Keep every message in writing (email is fine) so you build a clean, dated record. Never let a chase become emotional — the tone stays professional at every step precisely because the escalation is doing the work for you.

When to stop work

If your contract includes a suspension-for-non-payment clause — and it should — then continuing to deliver against an overdue invoice is a choice to increase your own exposure. The professional move, once an invoice is meaningfully overdue and the chase sequence has run, is to pause work and say so plainly: reference the clause, state that work is suspended until the outstanding amount is cleared, and confirm you will resume promptly on payment. Stopping work is not aggression; it is refusing to extend more unsecured credit. Continuing to build for a client who has stopped paying is how a manageable unpaid invoice becomes an unmanageable one.

Most non-payment resolves early, with leverage and a clear head. The escalation ladder exists so you always know the next rung — and so you never skip straight to the expensive one.

The escalation ladder

Non-payment is best handled as a series of defined, escalating steps rather than a single confrontation. Climbing the ladder deliberately keeps you in control, keeps the door open to a normal resolution for as long as possible, and builds the record you would need if it ever came to that. A typical ladder: (1) the chase sequence from section 05; (2) suspension of work under the payment clause; (3) a direct conversation to understand whether this is a cash-flow problem, a dispute, or avoidance — because each needs a different response; (4) a formal written demand; and only then (5) external options. Most disputes are resolved on the lower rungs; the value of knowing the whole ladder is that you never feel stuck, and you never over-react.

Keeping your leverage

Everything in this guide has quietly built toward one moment: the point where a client has not paid and you need them to. Your leverage at that moment is whatever value you have not yet fully handed over. This is why ownership transfers on final payment and not on delivery; why you invoice per milestone and not all at the end; why you never let work-delivered exceed money-received.

Do all of this within the bounds of your contract and the law — leverage means declining to do further unpaid work and withholding the final transfer of ownership per your agreed terms, not disabling systems the client has already paid for or holding their existing data hostage. Legitimate leverage is quiet and defensible. Anything that looks like sabotage hands the moral and legal high ground back to the other side.

Demand letters, small claims & beyond

When the lower rungs fail, the external options generally escalate in cost and formality: a formal demand letter (often from a lawyer, which alone resolves many cases by signalling seriousness); mediation or arbitration if your contract's dispute-resolution clause requires it; small-claims court for amounts under the local threshold, which is designed to be usable without a lawyer; and full legal action or a collections agency for larger amounts, accepting that both cost money and time and rarely leave the relationship intact.

Firing a client

Sometimes the problem is not one invoice but the relationship itself: a client who is chronically late, endlessly out of scope, abusive to work with, or simply costing you more than they pay. Ending such a relationship is a legitimate and sometimes necessary business decision. Do it the way you do everything else here — professionally and by the contract. Give the notice your termination clause requires, settle outstanding invoices and work-in-progress, transfer what the client has paid for, and keep the tone factual. A clean exit protects your reputation and your record; a messy one follows you. Firing a bad client is not a failure — it is capacity returned to the clients worth keeping.

Contracts protect a deal. A few structural choices protect you — so that a single bad project can never reach past the business and into your personal life.

The liability shield

Operating through a properly formed and maintained business entity — the exact form and name vary by country, but the concept is near-universal — creates a legal separation between the business's obligations and your personal assets. If a project goes badly and liability arises, that separation is what can keep the exposure contained to the business rather than reaching your home and savings. Trading in your own name as a sole individual generally offers no such shield.

The protection is real but conditional: it depends on actually maintaining the separation — keeping business and personal finances distinct, observing whatever formalities your jurisdiction requires, and not personally guaranteeing away the shield. The mechanics differ enough by location that this is a question for a local accountant or lawyer, but the principle is universal enough to state plainly: do not operate a software business without understanding what stands between a bad project and your personal assets.

Professional liability insurance

A liability cap in a contract limits what a client can claim against you; professional liability insurance (also called errors-and-omissions or E&O cover) is what actually pays a claim if one lands. The two work together: the contract caps the exposure, the insurance funds it, and the business shield contains anything that gets past both. For a software business the relevant cover typically addresses claims that your work was defective, caused loss, or infringed someone's rights.

Beyond being prudent, insurance is increasingly a sales requirement: larger and enterprise clients frequently require their vendors to carry a minimum level of professional liability cover before they will sign, so having it can be the difference between qualifying for a deal and being disqualified. Treat it as a cost of doing serious business rather than an optional extra.

Subcontractors & back-to-back terms

The moment you bring in a subcontractor, you take on a new risk: you are now on the hook to your client for work someone else performed. The protection is back-to-back terms — your agreement with the subcontractor should pass down the obligations you owe your client, so you are not promising the client something your subcontractor has not promised you.

Two points deserve particular care. First, IP assignment must flow through: if your subcontractor does not assign their work to you, you cannot assign it to your client, and you have a broken chain of ownership. Second, confidentiality and liability terms should be consistent up and down the chain. A mismatch — where you owe your client more than your subcontractor owes you — is a gap you personally absorb. Handle subcontractor agreements with the same seriousness as client contracts, because through you, they are client contracts.

Records & the paper trail

Almost every protection in this guide depends on one unglamorous habit: keeping a clean, dated record. Signed contracts and SOWs, change-request approvals, acceptance sign-offs (or the silence that triggered deemed acceptance), sent invoices, and the full chase correspondence — kept in order, they make every clause in your contract actually usable, because you can show what was agreed and when. In a dispute, the side with the clean paper trail is almost always the side in the stronger position.

This does not require heavy process. It requires that agreements are in writing, that important conversations are confirmed in a follow-up email, and that nothing that matters lives only in memory or a phone call. The delivery guide makes the same point about requirements; it is doubly true about money. Write it down, keep it, and you will rarely need it — which is exactly the point.

Everything above, compressed into things you can actually run: a pre-signature review, a ready-made chase sequence, and the vocabulary to hold your own in a contract conversation.

The “before you sign” checklist

Run this against any contract before you sign it. A “no” to any item is not necessarily a deal-breaker, but it is a prompt to push back or get advice — never a thing to sign past silently.

The chase-sequence templates

Adapt the wording to your voice, but keep the escalation and keep it in writing. These are starting points, not legal notices — the later, formal steps in particular are worth a lawyer's eye.

Glossary