How to Choose a Custom Software Development Partner

To choose a custom software development partner, judge how each supplier behaves before a contract exists, then write down what you will own, what counts as a defect and what happens when the plan changes. The fastest single test is to ask each supplier to work in a code repository created in your company's own account on day one, with their developers invited in as outside collaborators. A supplier who resists that is telling you who will control the work. This guide gives you nine criteria with the question that reveals each one, the contract terms worth writing down, a reference-check script and a scoring sheet for comparing proposals.

Portfolios tell you the least. Everyone shows their best work, and a screenshot says nothing about what the project cost, how late it was or whether anyone still uses it.

Nine criteria and the questions that reveal them

Each criterion comes with the question to ask, what a good answer sounds like and the answer that should worry you. Ask the same questions of every supplier and write the answers down, because you will score them later.

1. They investigate before proposing

A price produced from one conversation is a guess. It rests on assumptions about work the supplier hasn't seen, and those assumptions get corrected later at your expense.

Ask: What would you need to see before giving me a number you would stand behind?

Good answer: specific things. A walkthrough of the current process with the people who do it, sample records including the messy ones, documentation or test access for each system involved, and a list of who decides what. If the unknowns are large, they propose a short paid discovery before quoting the build.

Concerning answer: a detailed quote the next day, with no questions about exceptions, data ownership or what might change the estimate.

2. They will tell you not to build

A supplier whose only product is development will tend to find that you need development. The useful test is whether they can describe cases where the right answer was a configuration change, an existing product or a connector between tools you already own.

Ask: When did you last advise a client not to build something, and what did you recommend instead?

Good answer: a specific recent example, with the alternative and the reason.

Concerning answer: they can't recall one, or they say off-the-shelf software never fits. Existing products are often part of a sensible answer, and our guide to off-the-shelf software advantages and disadvantages shows where they hold up.

3. You meet the people who will do the work

A gap between the people who sell the project and the people who build it happens, particularly with larger suppliers. It isn't automatically disqualifying, but it should be stated, not discovered.

Ask: Who, by name, will work on this, for what share of their week, and can I talk to them directly?

Good answer: names and allocations, a direct channel to the lead engineer, and willingness to list key people in the contract with your approval needed to replace them.

Concerning answer: "a team of senior developers" with no names, or a structure where every question goes through an account manager. Detail degrades in relay.

4. They surface decisions instead of absorbing them

Every project contains decisions only the business can make: which system owns the customer record, what tolerance is acceptable on a match, whether an incomplete record is rejected or held. A supplier who absorbs these quietly picks whatever is easiest to build, and you meet those choices later as behavior nobody agreed.

Ask: What decisions will you need from us, and by when?

Good answer: a written decision list with an owner and a date for each item, kept up to date during the project.

Concerning answer: "We'll handle all that." It sounds like service and behaves like risk.

5. They ask about the unusual cases early

Any competent supplier can build the path where everything works. The cost, the timeline and most of the frustration sit in the cases where something is missing, duplicated, canceled or late.

Ask: What usually goes wrong in this kind of workflow, and where is that in your estimate?

Good answer: named failure modes for your kind of work, such as duplicate records after a timeout, records changed after a handoff or required fields left empty, with a line in the estimate for handling them.

Concerning answer: a proposal that describes only the successful path. Exceptions not discussed before the contract arrive afterwards as change requests.

6. Someone is accountable after release

Software meets real data, real volumes and real users after release, and some problems only appear then.

Ask: What happens in the first three months after release, what does it cost, and who decides what counts as a defect?

Good answer: a warranty period that starts at go-live, a written definition of "defect" tied to acceptance criteria, response times by severity and a named person. The contract section below has sample wording.

Concerning answer: "bug fixing is included" with no definition. That definition tends to narrow exactly when you need it.

7. You own what is built, in a form someone else could run

Ownership of source code is usually agreed. What often isn't agreed is everything needed to use it: the hosting accounts, the domain, the app store listing, the credentials and documentation another developer could follow.

Ask: If we ended the relationship the day after release, what exactly would we hold, and could another developer deploy it without you?

Good answer: they walk through something like the accounts checklist below without prompting and offer to work inside your accounts from the start.

Concerning answer: "You own the code" said with enthusiasm, while the system runs on hosting, domains and app store accounts in the supplier's name.

8. Scope change has a defined process

Scope will change. You will learn things during the work that you couldn't have known before, and some are worth acting on.

Ask: Can you show me a real change request from a past project, with how it was priced and approved?

Good answer: a short written format stating the change, its effect on cost and timeline and who approved it, priced from a published rate card.

Concerning answer: either extreme. "Everything is included" means the price is padded or necessary changes will be resisted. Treating every clarification as a paid variation produces a relationship dominated by negotiation.

9. The first useful outcome is close

A plan whose first delivery is six months away has six months of untested assumptions in it.

Ask: What is the smallest thing you could deliver that someone would use on its own, and when?

Good answer: a first phase that a named person can use for real work within weeks, even if it covers one workflow.

Concerning answer: phases named after build stages: design, development, testing, release. Those are internal milestones, not outcomes anyone can use.

What a good discovery deliverable contains

A paid discovery or planning phase is reasonable when important questions are still open. Judge it by what it produces. Our portability test: another supplier should be able to quote the build from the document alone. If they couldn't, you paid for a sales process. Use this table to judge any supplier's discovery output, including ours.

Sections of a discovery deliverable and how to judge them
Section	What good looks like	Red flag
Workflow maps	Current and future process for each workflow in scope, showing who does each step and where data is re-keyed today.	Only future-state screen designs.
Field ownership table	For every field shared between systems: which system owns it, who corrects it and which way it moves.	"Single source of truth" with no field-level detail.
Exception list	Each unusual case (missing, duplicate, canceled, late, changed) with the agreed behavior and the person who handles it.	No exception list at all.
Integration inventory	Each system, how it will connect (API, file or manual step), the plan tier it needs and who holds the credentials.	"Integrates with X" with no method.
Risk list with unknowns	Each unknown, how and when it will be resolved, and what it does to cost if the answer is bad.	No unknowns listed. Every project has some.
Phased plan	Each phase names who can use it and for what when it ends.	Phases named after build stages.
Estimate	A low and high figure per phase, with the assumptions that would move it.	A single number with no assumptions.
Decision log	Decisions already made, and decisions still open with an owner and a date.	Open decisions buried in meeting notes.

If the software will connect existing systems, the field ownership table and exception list should look like the ones in our guide to connecting business systems. If it replaces an older system, the discovery should also record what that system does without anyone noticing: scheduled jobs, embedded rules and reports other teams depend on. Our legacy system examples include a one-page sheet for capturing them.

This is what an estimate line with a range and its assumptions looks like. The example is illustrative:

Phase 1: Won deals create delivery projects automatically
  Usable by:  Delivery leads, for every new deal
  Estimate:   5 to 8 weeks
  Assumes:    CRM API allows deal updates on the current plan;
              delivery tool supports a custom "CRM deal ID" field
  If wrong:   add 2 to 3 weeks for a workaround, or a plan upgrade
  Open:       Who approves scope changes after handoff (Sales
              director, decision due before week 2)

Pricing models: who carries which risk

Every price is an estimate plus a decision about who pays when the estimate is wrong. The Federal Acquisition Regulation, the rulebook US federal agencies buy under, states the trade-offs plainly. A firm-fixed-price contract "places upon the contractor maximum risk" (FAR 16.202-1). A time-and-materials contract may be used only when it isn't possible "to estimate accurately the extent or duration of the work", it "provides no positive profit incentive to the contractor for cost control or labor efficiency", and it must include "a ceiling price that the contractor exceeds at its own risk" (FAR 16.601). Part 16 is being rewritten under the federal government's FAR overhaul, which as of September 2026 makes fixed price the preferred contract type, so the wording at those links may change. The trade-offs won't. Your business isn't a federal agency, but the logic carries over.

Four pricing models compared
Model	Who pays if the estimate is wrong	Fits when	Ask before signing
Fixed price	The supplier, so the price includes contingency you pay whether or not it's used.	Workflows, fields, exceptions and acceptance criteria are written down.	Who decides whether a request is a change? What is the rate card?
Time and materials	You.	The extent of the work can't yet be estimated.	What will I see each week? How much notice do I get before a budget threshold?
Capped time and materials	You up to the cap, the supplier beyond it.	Scope is mostly understood but details will move.	What exactly is inside the cap? At the cap, does work stop or does the supplier finish at its own cost?
Paid discovery, then a price per phase	You, for the discovery. Then as agreed for each phase.	Important questions are still open.	Can another supplier use the output? Is the discovery fee counted toward the build?

Because time and materials gives the supplier no built-in reason to be efficient, ask for a weekly report of hours by task against the plan, and a warning before any phase passes an agreed share of its budget. Our default threshold for that warning is 75 percent.

Whatever the model, most money moves through change requests. Ask these five questions and get the answers into the contract:

Who decides whether something is a change? The best answer is "the written acceptance criteria": if the request is already in them, it is not a change.
How is a change priced: from a rate card, or re-quoted each time?
Can we swap in new work of equal size by dropping something not yet started, without a fee?
How quickly does a change estimate arrive, and does work pause while we wait?
Where are approved changes recorded, and do they update the acceptance criteria?

Ownership in practice: the accounts checklist

"You own the code" is a sentence in a contract. Owning it in practice means your company holds every account the software needs to run, from the first day, and the supplier is invited in as a user. Fill in this checklist with the supplier before work starts, and again at handover.

Accounts your company should hold, with the supplier invited as a user
Asset	In your name means	How to check
Code repository	Created in your company's organization on GitHub, GitLab or Azure DevOps on day one. The supplier's developers are added to it, not the other way round.	You can see every commit and remove the supplier's access yourself.
Cloud hosting	The AWS, Azure or Google Cloud account and its billing are in your company's name. The top-level login uses a company mailbox, and its multi-factor device is held by your people. The supplier gets named user accounts.	Log in and find the production environment.
Domain registrar and DNS	The registrar account and the domain's registrant are your company. The supplier gets DNS editing access at most.	Log in to the registrar yourself.
App store accounts	Apple and Google developer accounts enrolled as your organization.	Your company's name shows as the seller on the listing.
Email sending, SMS, payments, maps and other APIs	Accounts and API keys created under your company and billed to you.	Every key is listed in the handover document with where it's stored.
Error monitoring, logs and analytics	Your accounts, with the supplier invited.	You can open the error dashboard.
Passwords and secrets	A shared vault your company owns.	Removing the supplier from the vault doesn't lose any credential.

Four details from the vendors' own documentation are worth knowing:

GitHub calls a person with access to your repositories who isn't a member of your organization an outside collaborator. That is the right role for a supplier's developers. GitHub also recommends at least two people with the owner role, because an organization with one unreachable owner can lose access to its projects. Make both of them your own staff.
If a supplier transfers a repository to you later, GitHub's transfer documentation says the original owner is added as a collaborator on the transferred repository, and webhooks, secrets and deploy keys stay associated with it. After a transfer, remove the supplier's access and replace every credential they created.
Apple requires an organization enrolling in the Apple Developer Program to have a D-U-N-S number, and the person who enrolls becomes the Account Holder and must have authority to bind the company. The enrolled organization's name is displayed as the seller. Start this early, and don't let the supplier enroll on your behalf.
Moving an app that is already published under a supplier's Apple account is an app transfer. The supplier's Account Holder starts it, yours accepts it, the app needs at least one version released on the App Store, and some things don't move, including an Apple Pay merchant ID.

With the repository and accounts in your name from the start, source code escrow adds little. Escrow was designed for the case where the supplier holds the only copy. If you already hold the live repository and the handover test below passes, an escrow agreement adds a fee and a release procedure for protection you already have.

Contract terms to write down

The wording below reflects common commercial practice. It is not legal advice, so have your lawyer adapt it to your contract. The US federal government's Digital Services Playbook asks for the same things when it buys custom software: frequent deliverables rather than multi-month milestones, software and data that stay under the buyer's control, a warranty period for defects at no extra cost, and a transition-out plan.

Assign rights on each paid milestone

If rights pass to you only on final payment, a dispute in month five can leave you without clear rights to four months of work you have already paid for. Tie the assignment to each payment instead:

On receipt of payment for each milestone, the Supplier assigns to the
Client all right, title and interest in the Deliverables for that
milestone, including source code, designs, documentation, database
schemas and infrastructure configuration. Materials the Supplier owned
before this agreement, listed in Schedule [X], remain the Supplier's.
The Supplier grants the Client a perpetual, irrevocable, royalty-free
license to use, modify and have others modify them as part of the
Deliverables.

Ask for Schedule X to be filled in before signing. A supplier who reuses its own libraries is normal. A schedule that turns out to cover most of the system is not.

Define "defect" against written acceptance criteria

Without a definition, every warranty report can turn into an argument about whether the software was ever meant to work that way. A definition tied to written acceptance criteria settles that in advance:

"Defect" means a failure of the delivered software to meet the
acceptance criteria agreed in writing for the relevant feature, or to
behave as described in the delivered documentation, when used as
documented. A request to change behavior that meets its written
acceptance criteria is a change request, not a Defect. The warranty
period for each release starts on the date that release goes into
production use. The Supplier corrects Defects reported during the
warranty period at no additional charge.

Start the clock at production use, not at delivery of the code, because many defects only appear with real data and real users. Add response times by severity if the system is critical, for example a response within one business day when a core workflow can't be completed.

Make handover documentation a deliverable

List it in the contract with its own acceptance test, so it gets written during the project rather than promised at the end. It should contain:

an architecture overview a new developer can read in an hour
how to set up a development environment from nothing
how to deploy, and how to roll a release back
every external service and account, with its owner, plan and renewal date
where each secret is stored (the location, never the value)
the data model and any scheduled jobs
a list of open-source components and their licenses
known issues and a runbook for the most likely failures

The acceptance test: a developer who hasn't worked on the project deploys it to a fresh environment using only the documents and the accounts you hold. If they can't, the handover isn't finished.

Name the key people

List the lead engineer and product lead in the contract. Replacing either needs your written approval and an overlap period for handover at the supplier's cost.

A reference-check script

Ask each supplier for three references: one whose project changed direction partway through, one who has been live for more than a year, and one of similar size and type to yours. How a supplier behaves when a plan stops working tells you more than how it behaves when everything goes well. Call rather than email, ask for twenty minutes, and use the same questions every time:

REFERENCE CHECK: [Supplier]      Reference: [Name, role, company]

1. What did they build for you, and who uses it today?
2. What was the first thing that went wrong, and how did they
   handle it?
3. How did the final cost and timeline compare with the first
   estimate? What caused the difference?
4. Were the people who sold the project the people who did the
   work? Who was your day-to-day contact?
5. When you asked for a change, how was it priced, and how long
   did it take to agree?
6. What happened in the first three months after release? Were
   fixes charged?
7. Do you hold the code repository and hosting accounts yourself?
   Have you checked?
8. Would you hire them for something more critical to your
   business? Why, or why not?
9. What would you do differently in the contract?
10. What should I have asked that I didn't?

Listen for specifics: names, numbers and a sequence of events. If a reference answers question 2 with "nothing really went wrong", ask question 3 again in different words. In our view, questions 8 and 9 get the most candid answers, because they ask about the future instead of inviting the reference to criticize someone.

A weighted scoring sheet

Score suppliers on evidence, with price kept separate so it doesn't swamp everything else. The weights below are our suggestion. Change them before you see any proposals, not after.

Weighted scoring sheet for comparing suppliers
Criterion	Weight	Scores 1 when	Scores 5 when
Investigation and discovery quality	20	Quoted without seeing the work	Discovery output passes the portability test
References	15	Vague answers, or no reference whose plan changed	Specific answers, and "yes" to question 8
Ownership and handover terms	15	Accounts in the supplier's name	Works in your accounts from day one; handover has an acceptance test
Named team you have met	10	No names	Named people with allocations, and key people in the contract
Exceptions in the proposal	10	Happy path only	Named failure modes with a line in the estimate
Pricing model and change process	10	No rate card or change format	Rate card, written change format, swap rule
After-release warranty	10	"Bug fixing included", undefined	Defect defined against acceptance criteria
First useful outcome	10	Phases are build stages	A named user works with phase 1 within weeks

Put the weights in B2:B9 of a spreadsheet and each supplier's scores in the columns to the right, starting with C2:C9. This gives each supplier a weighted score out of 5:

=SUMPRODUCT($B$2:$B$9, C2:C9) / SUM($B$2:$B$9)

Three rules make the sheet honest. First, treat ownership as a knockout: a supplier that won't work in accounts you hold is out, whatever its total. Second, have two people score separately, then discuss any criterion where they differ by two points or more, because a gap that size means they heard different things. Third, compare prices only among suppliers within about half a point of the top score, so price decides between comparable plans rather than rescuing a weak one.

If you'd like to test this sheet on us, bring your shortlist questions, the workflow you want built and any proposals you have already received. We'd start by reading those proposals for missing exceptions and ownership terms. For the record, we work week by week, every build includes a 30-day bug-fixing period after completion, and clients get weekly update meetings plus daily chat in a client portal. Our custom software development service begins by understanding the process before proposing anything to build.