Insights & Strategy

What to Put in a Software Development Contract Before You Outsource

Ascent24 Technologies
5 min read
Two business people shaking hands, with the Ascent24 logo

A good software development contract answers six questions in writing: who owns the code, where the code and accounts live, how finished work is accepted, how changes are requested and priced, what happens if a developer leaves, and how you get everything back when the work ends. If your draft is vague on any of these, fix it before you sign. This is a practical checklist for business owners, not legal advice, so have a lawyer in your country review the final contract.

Why this matters more now

More buyers are signing with small vendors and solo developers. In the Stack Overflow 2026 Developer Survey, 10.5% of respondents (2,213 people) said they work as a company of one, a freelancer or sole proprietor. Stack Overflow says that share more than doubled from about 4% the year before. A one-person shop can do excellent work, but there is no larger company behind it to absorb a dispute, an illness or a sudden exit. The contract has to carry more of that weight.

1. Put IP assignment in writing

Many business owners assume that if they pay for software, they own it. In the United States that is not automatic. The US Copyright Office's Circular 30 lists nine categories of commissioned work that can be a "work made for hire", such as a translation, a test or an atlas. Software is not on that list. So code written by an outside contractor usually belongs to the contractor unless the contract assigns the copyright to you.

What to include:

  • A clear assignment of all rights in the code, designs and documentation to your company, effective on payment.
  • A list of anything the vendor keeps, such as their own reusable libraries, with a licence for you to use it forever.
  • A statement on open source: which licences are allowed and that the vendor will tell you what is used.

2. Own the repository and accounts from day one

Ownership on paper means little if the code sits in the vendor's GitHub account. Create the repository, cloud account, app store accounts and domain under your company and give the vendor access. Write that into the contract, along with who holds signing keys and admin passwords. It is much easier to remove access later than to ask for a transfer during a disagreement.

3. Define acceptance criteria

"Delivered" should mean something you can check. For each milestone, list what the feature must do, which devices or browsers it must work on, and how long you have to test it, for example 10 working days. Say what counts as a defect and how fast it must be fixed. Tie payments to accepted milestones, not to dates alone.

4. Agree how changes work

Scope will change. Decide up front how a change is requested, who approves it, and how it is priced (a day rate, a fixed quote per change, or hours from a monthly pool). Ask for every change to be confirmed in writing before work starts, so the final bill has no surprises.

5. Cover developer replacement

If you hire a team, the people matter. Ask for:

  • Named key developers and notice before anyone is swapped.
  • A handover period when someone leaves, paid by the vendor.
  • Your right to ask for a replacement if a developer is not working out.

With a solo freelancer, agree what happens if they are unavailable for more than a set number of days.

6. Plan the exit before you start

Every engagement ends. The contract should say that on exit you get the latest code, database exports, documentation, credentials and a short handover call, within a fixed number of days, even if there is a payment dispute on other items. Add a notice period that lets either side end the contract without a long fight.

Other terms worth a line each

  • Confidentiality for your data and business plans.
  • Security basics: no production data on personal laptops, access removed at the end.
  • Warranty period for defects after launch, for example 30 to 90 days.
  • Which country's law applies and how disputes are handled.

Common mistakes

  • Signing the vendor's standard template without reading the IP section.
  • Paying the final invoice before you have the code and credentials.
  • Writing "the app" as the scope instead of a list of features.
  • Leaving app store and cloud accounts in a developer's personal name.

If you are still choosing how to outsource, our guide to staff augmentation, dedicated teams and project outsourcing compares the three models. Once you have shortlisted people, see how to test a developer's skills when they use AI coding tools.

Where Ascent24 can help

Ascent24 provides developers and dedicated teams for web, mobile and cloud projects. If you want to talk through a project and how code ownership and handover would work, email info@ascent24.io or send us your details.

FAQs

Do I own the code if I paid for it?

Not always. In the US, commissioned software is not one of the nine work made for hire categories, so you need a written assignment of copyright from the contractor.

Should the code be in my repository or the vendor's?

Yours. Create the repository and accounts in your company's name and give the vendor access.

What should acceptance criteria include?

What each feature must do, where it must work, how long you have to test it, and what counts as a defect.

Is a template contract enough?

It is a starting point. Add the IP, access, acceptance and exit terms above, and have a local lawyer review it.

Sources