Outsourcing Custom Software, Step by Step
To outsource custom software is to hire another company to design and write a system made for your business alone, under a contract that hands the finished code to you. This guide covers the buyer's half of that deal in seven steps, from the first brief to the day the vendor's access is switched off.
On this page
- 01Write a brief about outcomes, users and the systems it must connect to, not screens. Vendors only price the same project when they read the same brief.
- 02Shortlist three to five firms and judge the people who would write your code, from a code sample and references you call yourself.
- 03Put scope, short milestones, a change process, a warranty and an exit plan into the statement of work.
- 04Get a written assignment of the copyright. Under US law, paying for code does not by itself make it yours.
- 05Agree how each feature will be tested and accepted before it is built, then run the first 90 days on demos of running software.
- 06Write the handover into the contract while both sides are still on good terms.
Step 1: write a brief that three vendors would price alike
Quotes for the same idea often differ wildly because each vendor priced a different project in its head. A written brief removes the guessing. Two or three pages are enough, written in the words your users would use rather than as a list of screens.
The TechFAR Hub, the US Digital Service's guide for agencies buying agile software, starts from a product vision: who the product is for, the need it meets, the main benefit and the alternative it improves on. It asks buyers to state outcomes instead of a blueprint of how to build, because the technical detail is settled during the work. A private buyer gains from the same discipline.
What the brief has to say
- The problem, in one sentence, and what it costs you today in hours, errors or lost sales.
- The users: each role, roughly how many people hold it, and the devices they work on.
- The jobs the first version must do, five to ten of them, ranked.
- Every system it must talk to, named: accounting, payments, sign-in, your CRM.
- The data that has to move out of old tools, and about how much of it there is.
- The rules that bind it: regulated data, accessibility, where records may be stored.
- What is out of scope for the first version, stated plainly.
- A budget range and a date that matters, with the reason the date matters.
Name one person who can say yes
The federal Digital Services Playbook asks every project for a single product owner with the authority to make business, product and technical decisions. In a company, that is the person who can approve a change on a Tuesday afternoon without calling a meeting. Put that name in the brief. If nobody can hold the role, an outside team will stall whichever firm you choose.
Two free tools speed up the writing. The requirements document generator turns a few answers into a one page brief in the sections vendors expect, and the user story generator writes each job as a story with Given, When, Then criteria that step 5 reuses.
Step 2: shortlist three to five firms and test who would write the code
Start wide: firms recommended by people who have bought software, review directories such as Clutch, and teams whose products you already use. Then cut to three to five before asking for proposals. With more, nobody on your side reads each answer properly, and the comparison turns into a contest of brochures.
Send every firm the same brief, the same questions and the same deadline. Then weigh evidence over pitch. For agencies, the TechFAR Hub suggests oral presentations and a sample of code the bidder has written, with its results. A company can ask for both in a one hour call with each finalist, as long as the engineers who would do the work are on that call.
| Ask for | A good answer | A warning sign |
|---|---|---|
| The people who would write your code | Names, roles, where each person works and the hours they keep | "We assign the team after you sign" |
| A code sample from a similar build | A walkthrough of real code and its tests, led by an engineer who wrote it | Slides and screenshots only |
| Two references you call yourself | Recent clients with a build like yours, happy to talk by phone | Written quotes only, or references from years ago |
| The assumptions behind the price | Hours by phase, the integrations counted, the data volume assumed, what is excluded | One total with nothing underneath it |
| Their own code the build would rely on | A list of each framework or platform, with the license you would hold to it | "Our accelerator" with no license terms |
| What they would change in your brief | A question you had not thought of, or a feature they would cut from version one | Agreement with every line |
| How the engagement ends | A handover pack and a date for removing their access, in writing | No exit described at all |
Compare prices last, and compare them as rates. Our free quote checker divides a quote by its hours to show the hourly rate inside it. A bid far below the rest usually assumed less work, not more skill, and the gap returns later as change requests.
Then, before committing the whole budget, buy your favourite a small paid first phase. It tests the firm on real work for a fraction of the build cost.
Step 3: put the deal into a statement of work
Two documents usually govern an outsourced build. The master services agreement, or MSA, holds the terms that stay the same from project to project: liability, confidentiality, payment terms, ownership and governing law. The statement of work, or SOW, holds this project: what will be built, by whom, by when, for how much, and how both sides will know it is finished. The MSA should say which one wins if they disagree.
Nine clauses the SOW should carry
- Scope, written as outcomes and features, with an explicit list of what is out.
- Deliverables, each with the acceptance criteria that step 5 describes.
- Milestones a few weeks apart, each tied to software you can use rather than a document.
- The pricing model, plus the rate card for anything outside a fixed price.
- A change process: each change written, priced and dated before anyone works on it.
- The key people by name, and what happens if one of them leaves.
- Where the code, tickets and documents live, and whose name is on each account.
- A warranty period after acceptance, in which defects are fixed at no charge.
- A transition out plan for the day the contract ends.
Clauses 3, 8 and 9 come from the contracting checklist in the Digital Services Playbook, which asks for frequent deliverables rather than milestones months apart, a warranty period for defects found after release, and a plan for handing the service over at the end.
Clause 5 is where budgets go. In GoodFirms' 2026 cost survey, projects hit by scope creep cost 10 to 25 percent more. A written change request with a price and a new date does not stop change, which is often the right call. It turns each change into a decision someone signs.
Choose the pricing model before you compare totals, because each one puts the risk of an overrun on a different side. The models are compared on our custom software outsourcing page. Once the scope is agreed, our free SOW generator lays out deliverables, acceptance criteria and priced milestones as a PDF.
Step 4: secure the IP, and decide whether you need escrow
Paying for code does not make it yours. Under US copyright law the author of a work owns it from the moment it exists, and the TechFAR Hub's page on data rights says plainly that when the author is a contractor, the contractor owns it first. Ownership moves by written transfer: section 204(a) of the Copyright Act makes a transfer valid only when it is in writing and signed by the owner.
Calling the code "work made for hire" does not settle it. The US Copyright Office's Circular 30 lists nine kinds of commissioned work that a signed agreement can make for hire, among them translations, compilations, tests and atlases. A custom application does not normally fall into any of the nine, so a clause that only uses those words may leave the copyright with the firm.
Ask for an express assignment as well. Rules differ outside the US, so have a lawyer in your own country read the clause before you sign it.
Four things the contract and the setup must cover
- Assignment of everything written for your project, effective on payment, binding the vendor's staff and any subcontractors.
- A license to the vendor's own code: a list of each pre-existing framework, tool or platform your system needs, with a license that is perpetual, royalty free and transferable to whoever maintains the system next.
- An open source list: every component and the license it carries.
- Accounts in your name from day one: repositories, cloud hosting, domains and app store listings, with the vendor's engineers added as people you can remove.
The fourth is easy to set up. On GitHub, for example, an organization can give outside collaborators access to chosen repositories only, set the level of access for each person, and, where the organization requires two-factor authentication, make them switch it on before they can accept.
The clause that is easy to miss
That is the second item, the license to the vendor's own code. The TechFAR Hub records an Army order to customize dental radiology software that never addressed the underlying software; the vendor then sued for more than $1 million in licenses to it. Custom code is worth little if it cannot run without a component somebody else owns, so read that list before you sign.
When source code escrow is worth paying for
In source code escrow, an independent agent holds a copy of the code and releases it to you if agreed conditions occur, typically the vendor's bankruptcy, the cancellation of the project or a failure to keep maintaining the software. Some agents also check that the deposit can actually be built.
Escrow exists for code you license and do not hold. If your project's repository already sits in your own organization, escrow adds little for that code. Spend on it for the vendor's own components and for any hosted platform of theirs your system cannot run without, and ask for the deposit to be refreshed on a schedule and test built.
Step 5: agree how work is accepted, before it is built
Projects stall at "almost done" when nobody wrote down what done means. Acceptance criteria settle it feature by feature, in advance. Written as Given, When, Then, one reads like this: given a customer with an unpaid invoice, when they sign in, then that invoice is shown first with a button to pay it.
The acceptance plan in the SOW
- Criteria for each feature, written before the sprint that builds it.
- Targets that are not features: page speed, the browsers and devices supported, an accessibility level such as WCAG 2.2 AA, and the security checks the build must pass.
- Who on your side tests, on which environment, with what data.
- A fixed review window for each delivery, and what happens when it passes with no reply.
- Defect levels, and which of them block acceptance.
- What acceptance sets off: a payment, the start of the warranty, the transfer of ownership.
| Level | Example | Blocks acceptance? |
|---|---|---|
| Critical | Records lost or exposed, payments failing, nobody able to sign in | Yes |
| Major | A core job cannot be finished and there is no way round it | Yes |
| Minor | A workaround exists, or a rare case fails | No; fixed in the next sprint or the warranty period |
| Cosmetic | Spacing, wording or colour | No; listed and scheduled |
Watch for deemed acceptance: a clause saying a delivery counts as accepted if you do not answer within a set number of days. It is fair to the vendor, provided the window is one your testers can really meet. If they cannot, change the window rather than strike the clause.
Test as you go, not at the end. The TechFAR Hub's quality assurance guidance starts testing in the first sprint, keeps it going through the development cycles, and lists regression and release tests among its stages. A buyer who accepts small pieces every few weeks never faces one huge acceptance test with the money already spent.
Step 6: run the first 90 days on evidence, not status reports
The opening weeks show whether the engagement will work, and they are the cheapest time to change course. The Digital Services Playbook sets a useful bar: a first version that meets a core user need, in real users' hands, no more than three months after the project begins. Hold the vendor to evidence of that kind at each checkpoint below.
| Window | What you should be holding | The sign something is wrong |
|---|---|---|
| Days 1 to 14 | Every account opened in your name; a ranked backlog; a written list of risks; a development and a test environment; the first architecture decisions on paper | The team is still waiting for logins, data or answers from your side |
| Days 15 to 45 | A demo of running software every week or two; the code in your repository; a test site you can open and click through | Demos of designs and slides instead of software that runs |
| Days 46 to 90 | A first version used by real people, even a small group; defects logged and sorted by level; spend reported against budget | Each new feature arrives together with a change request |
A weekly rhythm worth insisting on
- A demo of software that runs, recorded so anyone who missed it can watch.
- A short written note: what shipped, what slipped, and what is waiting on you.
- A log of decisions, kept by your product owner rather than the vendor.
- Money spent against money planned, with a forecast to finish.
On day 30 and again on day 90, ask one question: would you sign this contract again today? If the answer is no, act while it is cheap. A clear SOW and code in your own accounts make switching vendors painful but survivable. Without them, switching means starting again.
Step 7: plan the handover while everyone is still friendly
Every engagement ends: at launch, after years of support, or in a dispute. The terms of the ending are far easier to agree while relations are good, so they belong in the SOW from the start, not in an email sent the week things go wrong.
What a handover pack contains
- Architecture notes: the parts of the system, how they connect, and why each big choice was made.
- Setup instructions that take a new developer from an empty laptop to a running copy. The Digital Services Playbook asks for exactly this, so people can join or leave a project quickly.
- Runbooks for deploying, rolling back, restoring a backup and changing a secret key.
- Every credential and third party account, moved into your control.
- Known defects and risks, written down rather than remembered.
- A recorded walkthrough with the engineers who built it.
- A date for removing the vendor's access, and a named person on your side who checks it happened.
Test the pack before the final payment. Ask someone outside the vendor, a new hire or a freelancer you trust, to set the system up from the documents alone. Whatever they cannot do is what the pack is missing, and the vendor is still contracted to supply it.
Seven ways outsourced builds fail, and the first sign of each
Failed engagements tend to fail in the same handful of ways, and each shows an early sign long before the money runs out. The right-hand column points to the step on this page that heads it off.
| Failure mode | The early sign | Prevented by |
|---|---|---|
| Every vendor quoted a different project | Quotes more than twice apart, none listing its assumptions | Step 1, the brief |
| The cheapest bid won, without the hours to deliver | A rate far below the others, or hours that cannot cover the features listed | Step 2, the shortlist |
| Nobody on your side can say yes | Questions wait a week; settled decisions get reopened | Step 1, the product owner |
| Change requests eat the budget | Every demo ends in a new request, and the end date keeps moving | Step 3, change control |
| The code is yours but its parts are not | A vendor framework or platform in the build with no license in the contract | Step 4, ownership |
| Ninety percent done, for months | Features demoed again and again but never formally accepted | Step 5, acceptance |
| No way out | Servers, domains or the repository registered to the vendor | Step 4 and step 7 |
None of the seven needs a dishonest vendor. Most grow from a brief nobody wrote, a question nobody asked and a contract that let both sides assume.
The checklist for outsourcing custom software, from brief to handover
Thirty checks, in the order the work happens. Tick them as you go; this browser remembers your ticks on this device only, and nothing is sent anywhere. Download the list as a PDF to share with whoever signs the contract.
0 of 30 checked
Step 1, the brief
Step 2, the shortlist
Step 3, the statement of work
Step 4, ownership
Step 5, acceptance
Step 6, days 1 to 90
Step 7, the handover
How we answer these steps when we are the vendor
We have been the outside team in this process since 2017, so here are our own answers to hold us to. The first call is free and lasts 30 minutes, and if we are a fit, you have our written scope and quote no more than two days after it. Discovery runs for two weeks at its own price. It finishes with either a fixed build price or advice to buy an existing product, and you keep what it produced.
On ownership, your company holds the repositories and cloud accounts from the first sprint, and you can remove any of our engineers from them. Under our MSA, everything we make specifically for your project becomes yours when the last invoice is settled. Code and tooling we owned beforehand, or wrote to reuse across clients, stays ours, so ask us, as you would ask anyone, which of those pieces your system relies on.
While the build runs, each week closes with a recorded demo of the software working. At the end, the handover pack carries architecture documentation, runbooks and a knowledge transfer session. Our standard MSA is available to read before you commit, from legal@digitalheroes.co.in.
Our Clutch rating is 5.0 from 66 verified reviews (checked 13 October 2026). Engagement models, prices and the builds we have delivered are on our outsourcing service page, and the facts you can verify about us without a call are listed on the custom software development company page.
Questions buyers ask before they sign
Is outsourcing a dying concept?
Not by the spending figures. Gartner's April 2026 forecast puts worldwide spending on IT services, the category that includes application implementation and managed services, above $1.87 trillion in 2026, up 9.0 percent on 2025. The live question for a buyer is not whether to outsource but which decisions to keep in-house, which is what this guide is about.
What is outsourcing software?
It is paying an outside company for software work your own staff would otherwise do: building a new system, maintaining one you already run, or adding engineers to your team. Outsourcing custom software is the first kind. The product is made for your business alone, and the contract moves ownership of its code to you.
What are examples of custom software?
A print shop where buyers design products in the browser and upload a CSV file to personalize every item in a print run, which we built for SpeedyPrint in South Africa. Others: a client portal showing each customer's orders and invoices, a quoting tool that holds one firm's pricing rules, a rota system for clinics, a mobile app for field technicians. Each is custom because it encodes one company's own way of working.
What are the biggest software outsourcing companies?
The largest are global IT services firms. Accenture reported $74.2 billion of revenue for its year to August 2026 and about 814,000 people, and Tata Consultancy Services reported 584,519 employees at the end of March 2026. For one custom build, though, the shortlist questions in step 2 tell you more than size does. For a ranked shortlist, see our offshore software development firms for US teams.
Who owns the code an outside firm writes for us?
Under US law, the firm does until it signs the copyright over to you in writing. Commissioned software does not normally fall into the nine kinds of work that an agreement can make "for hire", so the contract needs an express assignment of everything written for your project, plus a license to any of the firm's own code your system depends on. Step 4 lists what to check.
Do we need source code escrow?
Only for code you license and do not hold. If the project's repository is in your own organization from the first day, you already have the code, and escrow adds little. It earns its fee for a vendor's own framework or hosted platform that your system cannot run without, especially when the vendor is small or new.
Should we pay for discovery before a fixed price?
Usually, yes, unless your scope is already written to the level step 1 describes. A fixed price set before the requirements exist either hides a large buffer or gets renegotiated halfway through. A short paid discovery gives you a scope, a system map and a price you can take to another firm, and it tests the vendor on real work.
How long should acceptance testing take?
As long as your own testers need to run the criteria on realistic data, and no longer. We suggest agreeing a window per milestone that your team can really meet, often one to two weeks, and testing during every sprint so the final acceptance holds no surprises. Whatever you agree, write it into the SOW next to the deemed acceptance clause.
Can we outsource a build if nobody on our team is technical?
Yes, but buy differently. Choose a fixed scope or a team whose lead answers for the result, rather than individual engineers you would have to direct. Pay for discovery, and hire an independent engineer for a few hours at the shortlist and at each acceptance point. The one role you cannot hand over is the product owner from step 1.
Last reviewed .
Written a brief already? Test it on us.
Bring the brief from step 1, rough or finished. Calls are booked at least five days ahead, so our discovery lead has read it before you speak, and the 30 minute call itself is free. When the work fits us, the written scope and quote arrive within 48 hours of the call. Book a call.
Why work with Digital Heroes
115 people across five studios in New York, Delhi, London, Sydney and Lucknow, shipping ecommerce, web, software and mobile work for founder-led brands. Senior engineers only, no account-manager relay, and the same team from kickoff to launch.
- Shopify Select Partner, as listed in the Shopify Partner Directory
- Tier 1 registered supplier on the United Nations Global Marketplace, which requires audited company documentation
- Top Rated Plus on Upwork, the bracket for the top 3% of talent by client outcomes
- 397 public five-star-weighted reviews across four Fiverr gigs, from clients in 36 countries
- DUNS verified business, No. 650878346, so procurement can check us before signing
- Listed by Clutch in Top 1000 Global B2B Companies and Top Web Designers 2024
- Verified profiles on GoodFirms, DesignRush, Digital.com, AppFutura and TopDevelopers
- 2,000+ brands built across 40+ countries, with $50M+ in client revenue scaled
More from Shreyansh.
Co-Founder · Lucknow · 27 posts on the site
Published .
