What to Require in a Development Contract Before You Sign

Most founders read a development contract for the price and the timeline, then skim past the parts that actually matter once the relationship ends. The price clause protects you for the length of the project. The IP, repo, and exit clauses protect you after it, which is a much longer period of your life.

We've seen the failure mode from both sides: as the incoming team asked to take over a codebase, and as the studio a client eventually needed to exit cleanly. The pattern is always the same. The contract said the client owned "the deliverables," but nobody defined what a deliverable was, nobody handed over admin access to the cloud account, and the person who knew where the seed data lived left the agency six months ago.

None of this requires a lawyer fluent in software. It requires a founder who knows which five things to ask for before signing, and who asks for them in writing rather than trusting a verbal "of course, it's all yours."

IP assignment has to be explicit, not implied

In most jurisdictions, a contractor who writes code for you does not automatically transfer copyright just because you paid the invoice. Work-for-hire rules are narrower than people assume, and they vary by contract type and by country. If the agreement is silent on IP, or says something vague like "client will own the final product," you may not actually own the source code, the designs, or the underlying architecture.

Require a clause that assigns all IP in the work product to you, effective on payment, covering source code, documentation, database schemas, design files, and any custom tooling built specifically for your project. Carve out explicitly what the studio retains: their own internal frameworks, boilerplate, and any pre-existing libraries they reused. That carve-out is normal and fine. What's not fine is a contract where the carve-out swallows the whole project because everything got built "using our internal accelerator."

Ask directly: if this relationship ended tomorrow, what exactly would I own outright, and what would I be licensed to use? Get the answer in the contract, not in a sales call.

You need to own the repo, not just have access to it

Access and ownership are different things. A studio can give you a collaborator seat on a repository they control, and revoke it the day a dispute starts. Ownership means the repository lives in an organization account you control, with the studio added as a collaborator, not the reverse.

• The GitHub, GitLab, or Bitbucket organization should be yours from day one, or transferred to you within a defined number of days of contract signing.
• The cloud accounts (AWS, GCP, Cloudflare, Vercel) should be billed to and owned by your entity, with the studio granted IAM roles, not root credentials that are theirs alone.
• The domain registrar and DNS should sit in an account you control, even if the studio manages records day to day.
• Any third-party service accounts — Stripe, Twilio, SendGrid, analytics — should be created under your business, not the studio's, from the start.

This matters most in multi-tenant systems, where the repo, the CI pipeline, and the database migration history are the actual product, not the marketing site. If you're comparing how different vendors structure this kind of ownership handover, our post on choosing a development studio without getting burned goes into how to vet this before signing, not after.

Define handover as a deliverable, not a courtesy

A handover that happens because the studio is nice about it is not a handover. It's a favor, and favors are optional. Put a handover deliverable in the statement of work with a specific checklist and a date it's due, whether the engagement ends on good terms or bad ones.

1. Full repository transfer, including branch history and closed pull requests, not a fresh export of the main branch.
2. Infrastructure-as-code or a written runbook covering every environment variable, secret, and third-party credential in use.
3. A database schema dump and a description of any non-obvious business logic encoded in migrations, triggers, or seed scripts.
4. Documentation of the deployment pipeline: how a change goes from a commit to production, and what breaks if that pipeline is unavailable.
5. A recorded walkthrough or a live session where the outgoing team explains architecture decisions to whoever inherits the system.

We treat this checklist the same way whether we're the ones building or the ones inheriting someone else's codebase after migrating tenant databases off a decommissioned platform. The reconciliation report that gates a migration cutover only works if the source system's schema and credentials were fully documented going in. Handover quality upstream determines how expensive the next migration is.

Escrow is a fallback, not a substitute for good access

Source code escrow — where a neutral third party holds a current copy of the code and releases it if the studio goes dark or breaches the contract — sounds like insurance. It's worth having for large, long engagements. But it's a fallback for catastrophe, not a substitute for owning your own repo and credentials from day one.

The problem with relying on escrow alone is staleness. An escrow deposit made once at project kickoff is worthless eighteen months later if nobody updated it. If you go this route, require scheduled deposits — monthly or at each major release — and require proof of deposit, not just a promise that it happened.

Write the exit clause before you need it

Every development contract should specify how the relationship ends, under both good and bad circumstances, because the terms you can negotiate calmly before signing are much better than the terms you get to negotiate during a dispute.

• Notice period. How many days' notice does either side need to give to end the engagement, and what happens to work in progress during that window?
• Transition support. Is there a paid period where the outgoing studio answers questions from your new team, and how many hours does that cover?
• Payment on termination. What's owed for work completed but not yet invoiced, and is any of it refundable if the handover checklist above isn't met?
• Non-solicitation, not non-compete. Reasonable contracts prevent poaching each other's staff for a period; unreasonable ones try to stop you from hiring anyone who ever touched your codebase.

The exit clause you negotiate while the relationship is still friendly is always better than the one you negotiate after it isn't.

Where this advice bends

None of this is a reason to slow down a genuinely small engagement. If you're hiring one contractor for a two-week landing page with no backend, full escrow and a formal handover checklist is overkill; a simple IP assignment clause and repo ownership from day one covers it. Save the heavier structure for engagements building the system your business actually runs on: the platform behind your SaaS product, your core ordering flow, or anything with a database schema that outlives any one vendor relationship.

The tradeoff is time. Every clause above adds a negotiation round before work starts. For a scoped MVP meant to ship in weeks, that friction is real, and some founders reasonably choose speed over protection for a first version they expect to rebuild anyway. That's a legitimate call. Just make it consciously, not by accident because nobody raised the question.

If you're deciding whether to build this yourself, hand it to a studio, or buy something off the shelf, that decision comes before the contract does — our post on build versus buy walks through the five questions that settle it. Once you know you're building, start a project with these clauses already in the first draft, not the fourth.