Blog
Key takeaways:
Most guidance on how to hire a software development company stops at the shortlist. You get the questions to ask, the portfolio review, the reference calls, and then nothing, as though the hard part ends when you pick a name.
The hard part starts there. Knowing how to hire a software development company really means knowing what to settle in the four weeks after you choose: what the signature actually covers, who owns the code and from what moment, what happens when a deliverable fails its test, and whether you can leave.
This guide is about that stage, and it assumes the evaluation is behind you. Still choosing? Start with the 12 questions that belong to the shortlist, because nothing below repeats them.
A master agreement rarely describes your project. It sets the terms, and the work itself lives in a statement of work or an exhibit attached to it, which means the document everyone celebrates signing is often not the one that defines what you are buying.
That structure is standard and it is also where ambiguity hides. In one form services agreement filed with the SEC as an S-1 exhibit, the work is defined entirely in "succeeding Exhibits with project name, description and project cost," each separately signed. The master agreement itself names no deliverable at all.
So read the exhibit, not the agreement, and judge it on whether a stranger could test it. "A reporting module" is not a deliverable. "A dashboard showing the five metrics listed in Appendix A, filterable by date range, loading in under two seconds on the reference dataset" is one, because somebody can tell you whether it is finished.
Name the people as well as the work. Which engineers are assigned, and whether they can be swapped without your agreement, is the difference between continuity and a quarterly handover, and a firm that publishes its team is easier to hold to that than one that does not.
Write down what you owe them too, with dates. The same filed agreement makes the client responsible for supplying technical data, programs, files, documentation and test data, and a delay you cause is not a delay the agency can be held to.
This is the clause people assume is settled and most often is not. The World Intellectual Property Organization states the default plainly: the software developer automatically retains IP ownership unless a software development agreement assigns it to the client.
WIPO notes that ventures frequently assume paying for custom software grants them full ownership of the code. It does not. There are four distinct arrangements, assignment, licensing, work for hire and joint ownership, and only one of them gives you what most buyers think they are getting.
The detail that matters more than the model is when ownership transfers. WIPO recommends specifying the exact moment in writing: on payment, on delivery or on signature. That single choice decides what you own if the engagement ends halfway.
Stop the same engagement at the same point three times and the clause decides the rest.
The two SEC filings we read answer it in opposite ways. The S-1 form agreement assigns everything to the client immediately and irrevocably, with no condition attached, while the second, a filed development agreement attached to an 8-K, names source code as a deliverable handed over with the software. Agreements written from the developer's side commonly condition assignment on payment in full, which is a reasonable position and a very different outcome for you in a dispute.
Two further pieces belong in the same clause. Background IP is whatever tools, libraries and internal frameworks the agency owned before your project, and you will not get those: expect a carve-out and a license instead. Open-source components need an agreed list of acceptable licenses up front, because WIPO's advice to list them is cheaper than discovering a copyleft dependency in your core during due diligence.
Here is the clause that separates a document you can enforce from one you cannot, and the comparison is stark.
| Clause | Startup form agreement (S-1 exhibit) | Delaware company's filed agreement (8-K exhibit) |
|---|---|---|
| Acceptance testing | No clause at all | Tested against a mutually agreed acceptance test plan |
| Repeat testing | Not addressed | Repeated at reasonable intervals until criteria are met |
| Failure remedy | Not addressed | After three failures, client may terminate and the developer refunds fees within 14 days |
| Termination for cause | 30-day cure period after written notice | Immediate for unremediable breach, 30-day cure otherwise |
| Termination for convenience | Absent entirely | Either party, on 30 calendar days' written notice |
| Source code as a deliverable | Not named | Named explicitly, handed over with the software |
| Confidentiality survival | 2 years | 2 years |
Both are real agreements filed with the US Securities and Exchange Commission, and neither is a market standard. The second is governed by Malaysian law, so read it for mechanics rather than for US legal effect.
What the contrast proves is that these terms are choices, not boilerplate. One document gives you a tested, refundable, exitable engagement. The other gives you a 30-day cure period and no way out if the work is simply disappointing rather than breached.
So ask for three things specifically: a written acceptance test plan, a number of permitted failures before you can walk, and a deadline for the refund if you do. A firm that pushes back on all three is telling you something useful.
Every project changes. The question is whether changing it is a conversation or an argument, and that is decided by paperwork nobody reads at kickoff.
Three mechanics make the difference. Who can authorize a change, which the S-1 form agreement handles by having each side name a project manager responsible for authorizing and executing change orders. How fast an estimate comes back, so a two-day decision does not wait two weeks. And what rate applies, since change work is often quoted above the base rate.
Insist that changes are written. The alternative is a verbal agreement in a status call that one side remembers as a commitment and the other remembers as an exploration, which is the most common source of invoice disputes on the projects we inherit.
The same discipline carries into how the work is run day to day, and the practices that distinguish a quality outsourced team are mostly these ones written down rather than assumed.
Fixed price, time and materials, and a dedicated team are three different risk allocations, and the right one depends on how well defined the work is rather than on which sounds safer.
Fixed price suits work you can specify completely, and it prices the agency's risk into your number. Time and materials suits work that will change, and it moves that risk to you. A dedicated team suits continuing work where you want capacity rather than a deliverable, which is closer to staff augmentation than to a project.
The trap is fixing too much at once. You can fix the scope, the date or the budget, and you can usually fix two, but fixing all three means something gives silently, and what gives is quality.
Whichever you pick, settle support separately. Both filed agreements we read put ongoing updates and maintenance outside the development contract, one of them stating that support, maintenance, updates and new releases "shall be contracted under a separate agreement." That is normal and it means day 91 is a commercial conversation you should have on day one.
Ownership on paper is not ownership in practice. The accounts matter as much as the clause, and this is where engagements go wrong in a way the contract does not catch.
Both of those can be true at once, which is the whole problem.
A founder on Reddit described having a contract stating the app and the IP belonged to the company, plus owner-level access to the GitHub repository, and then discovering the production cloud project had been created inside the agency's own organization. Moving it was quoted as separate billable work. That is anecdotal, and the replies from other developers were unanimous that the client should hold the cloud account and grant the agency scoped access instead.
| What you hold | What the agency gets | Why it matters |
|---|---|---|
| Repository organization | Scoped write access | Your code stays reachable if the relationship ends |
| Cloud account and billing | Scoped roles on your project | Nobody else can switch off your production system |
| Domain and DNS | Delegated records as needed | The site stays yours |
| App store developer accounts | Upload and release permissions | Publishing does not depend on them |
| Analytics and error reporting | Member access | You keep the history |
Set all five up before kickoff rather than after, because retrofitting them is the awkward conversation this list exists to avoid. The other half of day one is human: one named decision-maker on each side, with an agreed response time, so the project does not stall waiting for an answer nobody owns.
Deloitte's 2024 global outsourcing survey of more than 500 executives puts the problem on the buyer's side of the table rather than the vendor's. Only 25% of executives reported seeing reductions in vendor service costs or improvements in service quality, and 70% said their own vendor management function is not fully mature. Deloitte's framing is that the maturity of internal governance and management capability is what limits the result.
That survey covers outsourcing broadly rather than software specifically, and the pattern matches what we see on software engagements. The first month is where the relationship is actually configured.
Week one is access, environments and a shared understanding of the problem. By the end of it the team should be able to run the application locally and deploy something trivial to a real environment, because that proves the pipeline exists.
Week two should produce the first working increment, however small. Not a design, not a plan: something deployed that you can click.
Week three is the one to watch, and the signals are behavioral rather than numeric. Demos should run on a deployed environment rather than slides. The agency should flag a risk before you notice it. Change requests should arrive in writing without you asking. And you should be able to clone the repository and build the application yourself, which is a handover rehearsal disguised as a sanity check.
Week four is the first honest re-forecast. If nothing in the estimate has moved after a month of real work, the estimate is not being maintained.
On iCopy, the leadership team spent several months assessing their options before choosing anyone, and the first thing the engagement produced was not code. It was a clickable prototype of the Nimbus platform, which iCopy then used to pre-sell its new service model before the product existed.
At VAULT our engagements tend to settle fastest when something like that exists before the build starts, because it means everyone argues about the same artifact instead of the same adjective. Their CEO, Bridgette Ferraro, suggested that any entrepreneur looking for a powerful ally in building their platform should look to VAULT and the team.
The handover clause is the one nobody negotiates and everybody eventually needs. WIPO's advice on termination names three things and is worth memorizing: ask for the source code, the documentation and the passwords.
A startup employee on Reddit described inheriting an outsourced build where, nine months in, the agency would not grant repository access and instead offered to prepare an estimate for the handover work. The poster's objection was that nobody accounts for handover in a contract. One widely upvoted reply argued that the work was done and paid for, so handover was an overdue deliverable rather than a new project.
The most useful comment in that thread came from someone running an agency, and it complicates the picture honestly. An agency may legitimately hold base modules it reuses across clients, and open-source frameworks cannot be assigned to anyone. What a buyer can reasonably demand is the project code plus a defined license to everything else, which is a more precise ask than "give me everything."
Three kinds of code, and only one of them can be signed over.
So name handover as a deliverable with a deadline, not as a courtesy. Specify the repository, the documentation, the credentials, the infrastructure configuration and a defined support window afterward.
What makes that package usable is whether a new team can run the system from it without the old one, which is the standard we apply when moving a project between teams.
Escrow is worth considering if you have no in-house engineers, and it is only worth the fee if three things are specified: that buildable source is deposited rather than a compiled build, how often it is refreshed, and what the escrow agent verifies before release.
Whether you got the hire right shows up in five questions you should be able to answer without opening the contract. Who owns the code today, and from what moment. What happens if a deliverable fails its test twice. What notice either side has to give. Who authorizes a change. And what you would receive, by when, if you ended it tomorrow.
If any answer is "I would have to check," check now rather than during the disagreement that makes you look. The firm you just chose will answer all five readily if the agreement was written to be used rather than to be signed.
A short technical due diligence pass at the end of the first month is also worth the day it costs, because the cheapest time to find out the architecture is wrong is while the relationship is still new.
If you are weighing an agreement in front of you now, contact us. We will read it from the buyer's side and tell you which clauses we would want changed before signing.
Once you have chosen the firm, how to hire a software development company comes down to five clauses: what the deliverable actually says, when IP ownership transfers, what happens when something fails acceptance, what notice either side must give, and what you receive on exit.
Those five decide what the engagement is worth if it goes well and what you are left with if it does not. The portfolio and the reference calls belong to the earlier stage.
No. WIPO states that the developer retains ownership by default unless the agreement assigns it, and that assuming otherwise is a common and expensive mistake.
Even with an assignment clause, expect carve-outs for the agency's pre-existing libraries and for open-source components, which cannot be assigned at all. What you can require is full ownership of the project-specific code plus a clear license to the rest.
A dedicated team suits continuing work where the scope keeps evolving and you want capacity you can direct. A per-project contract suits a defined outcome with a clear finish line.
The practical test is whether you can specify what done looks like. If you can, buy the outcome; if you cannot, buy the capacity and keep a short notice period.
It is negotiable, and the filings show how much it varies. One agreement we read allows either side to terminate for convenience on 30 calendar days' notice; another has no convenience clause at all and permits termination only for cause after a 30-day cure period.
Thirty days is common. What matters more is that a convenience route exists, since without one your only exit is to allege a breach.
Demos that only ever run on a laptop, risks you discover rather than get told about, change requests agreed verbally, and an estimate that has not moved despite four weeks of new information.
The sharpest single test is whether you can build and run the application yourself from the repository. If you cannot, you do not yet have what you are paying for, whatever the contract says.
An agreement is easiest to improve in the week before signature and hardest in the month after. Contact us and we will go through yours clause by clause, from the side of the person paying for the work.
We read these as builders rather than lawyers, so take it as commercial review and not legal advice. For the legal effect of any clause, ask a solicitor or an attorney in the governing jurisdiction.
