TL;DR: Most disputes over custom software are not about quality. They are about who owns what, what "done" meant, and what happens when someone stops replying. Nine clauses settle nearly all of it, and every one is easier to negotiate before work starts than after.
The contract is the only part of a software project you can fully evaluate before spending money.
You can't assess the code. You can't verify the portfolio. But you can read a document, and the document decides what happens on every bad day that follows.
Below are the nine things worth getting right, in rough order of how much pain they prevent. This is not legal advice and it is not a template. It's the list of questions a business owner should be able to answer about their own agreement.
1. Who owns the code, and when does ownership transfer
Ownership should be yours, and it should transfer as work is delivered rather than on final payment.
That second part matters more than it sounds. If ownership transfers only at the end, a project abandoned at 70% leaves you with nothing, having paid for most of it. Incremental transfer means a stalled project still leaves you holding what you paid for.
Watch for language granting you a licence to use the software rather than ownership of it. Those are very different, and the difference only surfaces when you want to hire someone else.
2. Where the accounts live
Three accounts, and all three should be in your name from day one: the code repository, the hosting, and the domain.
Developers often propose holding these because it genuinely is simpler during a build. Accept it only with a written transfer commitment, including a deadline in days and a statement that transfer costs nothing. A vague promise to "hand everything over at the end" is the most common way a straightforward exit becomes a negotiation.
3. What "done" means for each payment
Milestone payments are standard. The failure is defining milestones by phase name rather than by observable result.
"Design phase complete" cannot be verified. "Customer list and login working at a URL I can open" can. Every payment trigger should be something you personally can confirm without taking anyone's word for it.
If a milestone can't be described that way, it's usually because it isn't really a milestone.
4. What counts as a change, and what it costs
You will change your mind once you see the software working. A good contract expects this instead of punishing it.
What you want defined: the difference between refining something already in scope and adding something new, how new scope gets priced, and whether there's an allowance for revisions inside the base fee.
Watch both extremes. A contract where every request triggers a change order belongs to a shop that profits from your uncertainty. One where nothing ever does means the cost is recovered somewhere you can't see.
Scope changes are not always small. We removed an entire module from our own product in April 2026, replacing the roofing configuration's quoting tool with proposals because roofing work needs photographs and explanation a quote line cannot carry. Shipped code, deleted deliberately. On a client project that is exactly the conversation a change clause exists to make possible rather than adversarial.
5. What happens if they go quiet
The most common bad outcome in small software projects isn't fraud. It's a developer getting busy with a larger client while your project drifts.
Two clauses cover it. A response window, meaning a defined number of business days for replies, with a stated consequence if it lapses. And scheduled code delivery, meaning work lands in your repository at agreed intervals rather than in one lump at the end.
The second clause is the one that matters. A project delivered incrementally can be picked up by someone else. A project that exists only on the developer's laptop cannot.
6. What you receive at the end
List it explicitly: source code in your repository, deployment instructions, documentation of external services and their costs, database structure, and any design files.
The test for documentation quality is whether a competent developer who has never seen the project could run it from what you were given. If the handover fits on one page, it's probably too thin.
7. Who is liable for what
Expect the developer to cap their liability. That is normal and not a red flag by itself.
What to check is whether the cap is proportionate to the damage possible. If the software handles payments or holds customer records, liability capped at the last month's fee is not a serious allocation of risk. Also check who is responsible if a third-party service the app depends on fails, because the answer is often nobody.
8. What happens to the data
If the software holds customer information, the contract should say who can access it, what the developer may do with it, and what happens to their copies when the engagement ends.
This deserves more attention than it usually gets. Ask specifically what happens to data in their development and testing environments, because copies of production data routinely live there and are routinely forgotten.
Ask also for a written answer on how customer records are kept separate from other clients' data, in plain language. We treat that as a design question rather than a contract question and write a threat model before building anything that touches data or money, which is why there are 138 of them in our repository. The contract should reflect whatever the answer is.
9. How it ends
Both sides should be able to exit. What matters is what you hold when it happens.
A termination clause should state what you receive, what you owe for work completed, and how long transfer takes. If the contract is silent on termination, the answer defaults to whatever the parties can negotiate under pressure, which favours whoever holds the accounts.
The single question that reveals the most
Ask a prospective developer: "What does this contract say happens if I want to leave in month three?"
The answer tells you whether they've thought about your position or only their own. A developer who answers clearly and without defensiveness is one who expects to earn the relationship rather than rely on the exit being painful.
If the answer is that they've never had a client leave, that isn't reassurance. It's an untested clause.
Frequently Asked Questions
Do I need a lawyer to review this?
For a small internal tool, an informed read against this list is usually proportionate. For anything touching payments, customer records, or a build large enough to hurt if it fails, a few hours of legal review at the contract stage is inexpensive compared to the exposure. The clauses on ownership, liability and termination are where legal input pays for itself.
What if the developer uses their own standard contract?
That's normal. Standard contracts are written to protect the party who wrote them, which is expected rather than sinister. Read it against the nine items above and ask for amendments where it's silent. Willingness to amend is itself a useful signal.
Should the contract name specific technologies?
Generally no, and pinning them can hurt you. What should be specified is that no component requires a licence or subscription you haven't been told about, and that the finished software can be hosted somewhere other than the developer's own infrastructure.
What about non-compete or exclusivity clauses?
Be cautious with anything preventing you from hiring another developer to work on the software. That effectively converts ownership into dependence. A reasonable version protects the developer's own reusable components; an unreasonable one restricts what you may do with your own product.
Is a fixed price or hourly better?
Fixed price transfers risk to the developer and tends to produce firmer scope boundaries. Hourly transfers risk to you and tends to accommodate change more easily. Neither is safer by default. What makes either work is the same thing: verifiable milestones and a written definition of scope.
If you're reviewing an agreement now and can't answer where the code lives, what "done" means, or what happens if you leave in month three, those are the three to resolve before signing. That applies to our contracts as much as anyone's.
See custom app development or start a discovery call. Related reading: eight checks for vetting a developer, what custom development actually costs, and what actually happens during a build.
Sources
- ClickWerxs platform repository — 138 STRIDE threat models written before their corresponding code; roofing quoting module removed in favour of proposals, April 2026. First-party operator data.
ClickWerxs builds custom software for businesses and earns revenue from those engagements. This post reflects our direct experience building and operating our own platform, not independent third-party research. Nothing here is legal advice; contract law varies by jurisdiction and by agreement. Consult qualified legal counsel before signing or amending a development contract.
Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut