How to Choose a Software Development Partner (Without Getting Burned)

Verify the Answers Against Artifacts

The questions above are the right ones, and a prepared partner can answer every one of them correctly whether or not they actually work that way. Interviews reward preparation. Narration and artifacts do not, because both carry details only a participant can supply. Start with the version that costs nothing: ask them to walk through the most recent production incident on a system they still support, end to end. A rehearsed story holds together until you ask who approved the merge that shipped the defect and when, whether the rollback was a redeploy or a migration someone reversed by hand, and whether the first signal came from monitoring or from a user.

For claims about capability rather than conduct, ask to see one thing that would exist only if the claim were true. An NDA is a real constraint and not a blocker: redacted repositories, internal tooling, open source contributions, and a screen share driven through their own workflow all clear that bar. Ask for whichever of these matches the claim you want to test.

• A pull request with the review comments still on it. Approvals with no comments across an entire branch tell you what review means there.
• The CI configuration file, which states plainly which checks are required before a merge is allowed: tests, linting, type checks, dependency audit.
• A test run with its totals and its wall clock time, plus whether a failure blocks the build. A suite that takes forty minutes is a suite that gets skipped.
• The onboarding document a new engineer reads on day one of a past project, and how long it takes that engineer to get the application running locally.
• One architecture decision record or design note: a decision, the options rejected, and the reason.
• A runbook or an escalation policy for a system they currently support, showing who is paged and what the severity levels actually mean.

Read the Contract for Ownership and Change Control

Ownership of the code is a contract term, not a default. Under United States copyright law, software written by an outside contractor does not become work made for hire simply because it was commissioned: the second prong of 17 U.S.C. 101 lists nine categories of specially ordered works, and software is not among them. A contract that says work made for hire and stops there can leave copyright with the people who wrote the code. The clause that actually transfers ownership is a present assignment of all right, title, and interest, with a further assurances obligation so that someone is still required to sign paperwork after the engagement ends. Your counsel drafts this, but you should know what the default is if nobody does.

The second ownership question is what your product depends on that no assignment covers. Third party dependencies carry their own licenses, and copyleft obligations attach to distribution: GPL terms trigger when you convey a binary, and AGPL section 13 extends the source offer to users who interact with a modified version over a network, which describes most hosted products. Ask for a dependency inventory with licenses attached, in CycloneDX or SPDX form, and ask what generates it in CI so it stays current instead of being assembled once for the contract.

Change control is the other place to read closely, and the failure mode is not that changes are forbidden. It is that the specification is silent on something, both sides read the silence in their own favor, and the disagreement surfaces at the milestone when it is most expensive. Ask what the contract says the default reading is when a requirement is ambiguous, and who decides. Whatever else you delegate to counsel, read these clauses yourself.

• Whether the assignment takes effect as work is created or only on payment in full, and what you hold if the engagement stops mid milestone.
• License terms for any vendor owned framework or library embedded in your product, including survival after termination and transfer on sale of the company.
• Ownership of the material that is not the product: build scripts, infrastructure definitions, database migrations, test fixtures, CI configuration. A successor team needs all of it, and it is routinely left off the deliverable list.
• Whether the partner may reuse components from your build in other clients' work, and how narrowly reusable is defined.
• Change control: who can raise a change, who prices it, and how long a written estimate stays valid.
• What happens to the repository and the running environments during a payment dispute. It is the clause you will care about most on the one occasion you care about it at all.

Own Your Accounts From the First Day

The most expensive mistake in an outsourced build is usually not code quality. It is discovering, at the point of transition, that the infrastructure your product runs on is registered to somebody else. This happens by accident rather than by intent, because it is faster for a partner to create an account than to wait for you to create one and add them. Ask for the reverse arrangement: you create and hold each account, then invite them as a member or a delegated administrator, so access is granted and revoked rather than transferred.

Undoing it afterward ranges from a support ticket to a rebuild, depending on the service. A change of registrant on a domain triggers a sixty day lock on transferring that domain to another registrar under ICANN's transfer policy. Apple and Google both support moving a published app to a different developer account, but the receiving account has to be enrolled and in good standing, the app generally needs at least one released version, and apps using certain entitlements cannot be transferred at all. Cloud accounts can usually change billing ownership, but resources bound to the old organization's identity provider, its private DNS zones, or its per account quotas do not always follow. Settle the whole inventory at kickoff, before the first deployment.

• The cloud provider account itself, including the root or owner identity and the billing relationship, not an IAM user inside someone else's account.
• The domain registration and the DNS zone, held in your registrar account, with registry lock enabled on the names that matter.
• The source hosting organization. Repositories created in an individual's personal namespace do not move with the team, and the organization is what holds branch protection rules and audit history.
• The CI/CD provider and its secrets store, which is where deployment credentials actually live.
• App store developer accounts enrolled under your legal entity, including the D-U-N-S number Apple requires for an organization account.
• Every third party service the product calls: payment processor, email and SMS gateways, error tracking, analytics, mapping. Each has its own owner field and its own set of API keys.
• Signing and trust material: TLS private keys, code signing identities and provisioning profiles, and whoever is able to reissue them.

Rehearse the Handover Before You Need It

Every engagement ends, and whether the ending is a handover or an excavation is decided long before the final month. Test it early rather than assuming it. At the first milestone, have someone outside the build team clone the repository and bring the application up locally from the written instructions alone, with no help from the authors, and time how long it takes. What that exercise exposes, an undocumented environment variable, a manual seed step, a certificate that exists on exactly one laptop, is what a real transition would expose later under worse conditions and with less goodwill.

Meeting the assigned engineers answers half of the continuity question. The other half is what happens when one of them is gone: whether more than one person on their side has ever deployed your system, whether substituting someone requires your consent or only notice, and how a replacement is brought up to speed. Ask the same question about your own organization, because a clean handover still strands you if nobody on your side can approve a production change or read enough of the code to judge a proposal. Whatever the ending looks like, the package that makes it survivable contains the following.

• A repository that builds from a clean checkout on a machine that has never seen the project, with the toolchain version pinned in a file rather than described in a message.
• Infrastructure defined as code for every environment, so deployments can be recreated rather than recalled.
• A migration history that runs from an empty database to the current schema, and a documented way to load realistic test data.
• A credential inventory: which secrets exist, which service each belongs to, where they are stored, and who is able to rotate them.
• A runbook covering deploy, rollback, backup restore, and the date the restore was last actually performed rather than last documented.
• Notes on the parts no reader can infer from the code: the integration contracts, the scheduled and asynchronous jobs, and the failure modes that are silent.

When a Build Is Not the Answer

Some requirements that get described as custom software do not need a build at all. The signal is that the proposed system would mostly move records between products that already publish APIs, or would reproduce what a configurable product already does out of the box. Price that alternative before scoping a build, and price it honestly, including the workarounds a packaged product would force onto the process.

A build earns its cost under conditions worth naming. The logic is specific enough that no packaged product models it, and it changes on your schedule rather than a vendor's. The data cannot leave an environment you control. The system you have to integrate with publishes no API, so the work is the integration and the interface is the easy part. Or a per seat tool scales with headcount while the workload it supports does not. If none of those hold, the honest recommendation is configuration, integration work layered on an existing product, or nothing.

Buying is not free either, and the comparison is not a license fee against a build. Data migration, integration, administration, and the process changes a packaged product imposes are real line items, and so is the exit: ask what the export format is and whether it carries the relationships between records or only the records. The middle path is often the correct one, which is buying the standard parts and building only the piece that is genuinely specific to you, joined through documented APIs and webhooks. The signals that point away from a custom build are usually visible in the first conversation.

• The workflow is a common one, such as invoicing, ticketing, scheduling, or CRM, and your version of it differs mainly in vocabulary.
• The volume is small enough that a scheduled script against existing APIs would cover it, and nobody has counted the records to check.
• The requirement is still changing week to week, which is a discovery problem rather than a construction problem.
• No one internally is going to own the software after delivery, which means the second year of maintenance has no owner either.
• The real driver is one report, and an existing system could produce it given access to the right data.