What a Good Contract With a Dev Team Actually Looks Like

Nobody reads the contract when things are going well. You read it the day the relationship breaks, when the deadline has slipped for the third time, when you want to leave and take your product with you. That’s the day you find out what you actually signed.

And here’s the uncomfortable part: the contract in front of you was almost certainly written by the vendor’s lawyer, to protect the vendor. That’s not a conspiracy. It’s just whose lawyer drafted it. The default document optimises for the person who wrote it, and the person who wrote it wasn’t you.

I’m not a lawyer, and none of this is legal advice. But I’ve taken over four builds after the agency relationship broke, and every time the founder was stuck in the same spot: not because the code was bad, but because the contract they’d signed gave them no leverage to get their own product back. The same handful of clauses were missing from all four. Here’s what to make sure your lawyer puts in before you sign.

Own the Code, Don’t License It

This is the one that ends careers of good ideas. You assume that because you paid for the software, you own it. Legally, that is not automatic. In most places, whoever writes the code owns the copyright by default, and it only becomes yours if the contract explicitly assigns it.

So the clause has to say the work product is assigned to your company. Present tense. “The Developer hereby assigns” beats “the Developer will assign” or “the Developer grants a licence.” A licence means they still own it and you’re renting. A future promise to assign means the transfer hasn’t happened yet, and if the relationship sours before it does, you’re negotiating for something you thought you’d bought.

And “the code” is bigger than the code. Assignment should cover the repositories, yes, but also the designs, the database schema, the infrastructure configuration, the deployment scripts, and any accounts created for your project. I have seen a founder own their application source and still be held up because the vendor “owned” the server setup that made it run.

Pay for Working Software, Not for Time or Calendar

There are three ways to structure payment, and they are not equally good for you.

Hourly with no cap is the worst. It rewards the team for taking longer, because longer is literally more revenue. There’s no built-in reason to finish. If you go hourly, you need a cap and a written estimate of hours per deliverable, so “we went over” is a conversation, not a surprise on the invoice.

Time-based milestones (“30% at week four, 30% at week eight”) are only slightly better. They pay for calendar passing, not for anything working. Week eight arrives, the money is due, and the honest question of whether anything actually functions never gets asked.

The structure you want ties each payment to working software that is deployed and that you can use. Not a demo. Not a screen recording. A thing running on a real URL that you can log into and try to break. “Payment three is due when users can sign up, create a project, and invite a teammate, live in production” is a milestone. “Payment three is due at week twelve” is a calendar reminder with your money attached.

This is where I have to be honest about my own bias. A team that’s confident in how it works is happy to be paid this way, because it plans to ship working software regularly anyway. A team that resists tying money to deployed, usable outcomes is telling you something about how its projects usually go. We run our own work this way on purpose, so read the recommendation with that in mind, then notice that the logic holds regardless of who’s giving it.

Access From Day One, Not “At Handover”

“We’ll hand everything over at the end” is the single most expensive sentence in a bad contract. Handover is not a deliverable, it’s a promise, and promises are what you’re left holding when things go wrong.

Your company should own the accounts from the first day of the project, with the dev team added as collaborators: the GitHub or GitLab organisation, the cloud account (registered to your company email and card), the domain in your registrar account, and every third-party service, the payment processor, the email sender, the error tracker, on logins you control.

The team works inside your accounts. They don’t build in their own walled garden and pass you the keys at the finish line, because that finish line is exactly where leverage gets used.

If you want the deeper version of how to lock this down technically, there’s a full guide on actually owning your code.

A Clean Exit, Not a Hostage Negotiation

Every contract should tell you how to leave, and leaving should be boring.

A termination clause should let either side end the engagement with reasonable notice (30 days is common), settle for work actually completed up to that point, and part ways without anything being withheld. Crucially, termination must not touch your ownership or your access. You already own the code and the accounts by then, so ending the contract just stops future work. It doesn’t claw anything back.

Read carefully for the traps. A clause that lets them stop work but keep the accounts is a trap. A clause where IP assignment is “void on termination” is a trap. A notice period so long it’s effectively a lock-in is a trap. The question to ask your lawyer is simple: “If I want to walk away next month, what exactly do I lose?” The right answer is “nothing but the work they’d have done next month.”

Documentation and a Warranty, Named as Deliverables

Two things almost always get left out, and both cost you later.

Documentation has to be a named deliverable, not a vague good intention. If it isn’t written into the contract as something they owe you, it’s the first thing dropped when the timeline gets tight. At minimum you want a README that lets a new developer get the project running, notes on how it’s deployed, and a list of the third-party services and where their keys live. The test is blunt: could a developer who has never met this team take over the project from the documentation alone? If not, you’re locked in to the original team whether you like them or not.

A warranty period is the other one. For some defined window after each deliverable (30 to 90 days is reasonable), bugs in the work they delivered get fixed at no extra charge. Without this, a bug found the day after launch becomes a new billable project, which quietly rewards shipping something fragile and charging you to stabilise it afterward. A warranty flips that: it’s in their interest to hand you something that actually holds up.

Scope You Can Point At, and a Change Process

Vague scope is where good relationships go to die. If “the platform” is never written down precisely, then every argument later becomes “that was included” versus “that’s extra,” and you’ll lose that argument because you can’t point to the document.

You don’t need a 90-page specification. You need a scope specific enough that both sides can tell whether something is in or out: the core features, what each roughly does, and an explicit short list of what is not in this phase. That “not included” list feels pedantic to write and saves you thousands.

Then, because scope always changes, you need a change process that both sides agreed to in advance. New feature requested, cost and time impact written down, you approve it before work starts. That’s it. This protects you from surprise bills and protects them from doing free work, which is why a fair team wants it as much as you do. The absence of a change process is what lets “scope creep” become a weapon pointed in whichever direction suits the vendor that week.

None of this makes you adversarial. A good team reads this list and nods, because every clause that protects you also removes an ambiguity that could bite them. The teams that fight it are telling you, for free and before you’ve paid a cent, exactly how the relationship is likely to end.

Before You Sign

You don’t need to become a lawyer. You need to walk into the review knowing which six things to insist on, so the lawyer you hire drafts them instead of rubber-stamping the vendor’s template. Hand them this list.

If the contract in front of you already fails half of these, that’s worth a second opinion before you sign, or before you try to leave. It’s the situation we get pulled into most, and it’s a lot cheaper to look at now than after the dispute starts.