How to hire a software development company

Before you compare rates or portfolios, decide how the money is going to flow, because that single choice moves more risk than any negotiation over an hourly number. The three models below cover almost every arrangement you'll be offered:

1. Fixed-price contract

   One agreed price for a scope you've written down, paid in stages as the work ships. The vendor carries the risk of misjudging the effort, so it prices carefully and has every reason to move fast. It fits small, fully specified builds and MVPs that can finish inside roughly four months, which is most first small business projects.

2. Time and materials

   You pay for the hours actually worked. It's the honest choice for medium projects with evolving scope, real discovery, or research nobody can spec up front. The catch is that the overrun risk sits with you, so always attach a not-to-exceed cap and acceptance gates so the meter can't run without results.

3. Dedicated team

   A fixed monthly fee for a ring-fenced group of engineers working only on your product. It fits long-term products, roughly eight months and up, that need a sustained roadmap rather than a one-off delivery. It's the most flexible model and the one that most rewards a client who can manage a team directly.

The honest framing is risk allocation, not one model being universally better. A fixed-price contract shifts the overrun risk to the vendor, who prices in a premium for taking it and may be tempted to cut corners or scope if the work runs long. Time and materials keeps the risk with you: you pay only for real hours, but the meter runs whether or not anything ships, so a not-to-exceed cap is what turns it from open-ended into bounded. A dedicated team sits in between and rewards a client who can steer the work directly.

Whatever the model, the payment schedule matters as much as the total. A defensible split is a deposit of roughly 20 to 30 percent, then 40 to 50 percent released across milestones as they ship, then a final 20 to 30 percent on delivery and sign-off. Treat 100 percent upfront and 100 percent only on completion as red flags in their own right: both dump the entire risk on one party¹.

Here's the vocabulary you'll meet throughout this guide, in plain English:

Fixed-price contract

A single agreed price for a fully specified scope, set before work starts. The risk of misjudging the effort sits with the builder, not you. It fits small, well-defined builds, MVPs, and migrations, and it's the model behind milestone billing.

Time and materials

Billing by the hour or day for however long the work takes. It suits medium work with evolving scope or genuine discovery, but the risk sits with you: slower work costs more. A not-to-exceed cap puts a ceiling on it.

Dedicated team

A fixed monthly fee for a ring-fenced group of engineers who work only on your product. It fits long-running products, roughly eight months and up, that need a sustained roadmap, not a one-off build with a clear finish line.

Work made for hire

A copyright term people misuse. For a commissioned outside developer, 'work made for hire' only applies to nine narrow categories of work, and custom business software isn't one of them. Labeling a contract that way does not, on its own, transfer the code to you.

IP assignment

The clause that actually transfers ownership. A present-tense assignment ('Developer hereby assigns...') moves the copyright to you when it takes effect. A vague promise to assign it later may never transfer anything, so the exact wording matters.

Source-code escrow

A three-party agreement where a neutral agent holds a copy of your source code and releases it to you if the vendor goes bankrupt or abandons the work. It's a continuity backstop, not a substitute for owning the code outright.

Acceptance gate

A checkpoint where you review a milestone against agreed criteria before releasing payment for it. Tying money to acceptance, not to the calendar, is the simplest protection against paying ahead of what's actually been delivered.

These patterns show up again and again in practitioner write-ups of engagements that went wrong³. Read them as tripwires, not deal-breakers on their own: any one is a reason to slow down and ask a harder question.

1. The bait-and-switch team

   You meet polished senior engineers in the sales meeting, then the actual work goes to unvetted juniors billed at senior rates. The fix is simple: ask for the CVs or LinkedIn profiles of the specific people assigned to your build before you sign, not the agency's highlight reel.

2. The 24-hour perfect quote

   A precise price that lands suspiciously close to your budget, delivered before anyone could have understood the work, usually means the vendor under-scoped on purpose and plans to recover the difference through change orders later. A real quote follows real questions about scope, integrations, and edge cases.

3. The lock-in dodge

   Ask one question: can I take the full codebase to another agency tomorrow? Anything short of an immediate yes is lock-in. 'We'll transfer it when the project is complete' is a yellow flag on its own; the code should live in a repository you control from the first commit.

4. The all-upfront payment

   A demand for the whole fee before work starts, or the whole fee only on completion, both put the risk entirely on one party and strip out the incentive to deliver. A healthy structure spreads payment across a deposit, milestone payments, and a final payment on your sign-off.

5. IP evasiveness

   Vague or shifting answers about who owns the finished code, the repositories, and the accounts are the most expensive red flag of all, because the legal default in the US favors the developer, not you. Get ownership pinned down in writing before the contract is signed, never after.

One belt-and-braces option worth knowing about is source-code escrow: a three-party agreement where a neutral agent holds a copy of your source and releases it to you if the vendor goes bankrupt or walks away mid-build⁵. It's a continuity backstop for larger engagements, not a replacement for owning the code outright, which is the next section.

Start from the default, because it's the opposite of what almost everyone assumes. When you commission an outside developer and the contract says nothing about ownership, the copyright in that code stays with the developer, not with you, even though you paid for all of it⁶⁷. This isn't a loophole. It's the baseline rule, and the Supreme Court settled the principle in Community for Creative Non-Violence v. Reid, holding that a commissioned creator was an independent contractor whose work was not automatically a "work made for hire," so the copyright did not pass to the party who paid⁸.

People try to solve this by stamping the contract "work made for hire," and for software that label almost never works. A commissioned work made for hire has to fall into one of nine narrow statutory categories, and custom business software isn't one of them, so the label alone transfers nothing⁹. What actually moves ownership is an assignment. And it has to be worded carefully: use a present-tense assignment ("Developer hereby assigns...") rather than a promise to assign later, which may never take effect⁷. The transfer also has to be in writing and signed to be valid¹⁰.

So the practical checklist for any contract you sign:

• A present-tense IP assignment of every deliverable, effective on final payment, in your name.
• The full source in a repository you own and can access at all times, not one the vendor controls and hands over later.
• No lock-in to the vendor's hosting, domains, or accounts, so nothing you paid for is held hostage by a login.
• Optional source-code escrow if the engagement is large enough that continuity is a real concern.

Converging vetting checklists all point at the same four areas, and the red flags cluster around evasiveness: refusing to let you meet the engineers who'll do the work, references you can't actually reach, large upfront demands, and dodgy answers on ownership¹³. The good news is that the two most useful checks are also the cheapest.

Reference-check the way a buyer should: 54 percent of B2B buyers talk to current users before they commit, and 77 percent consult third-party reviews, so ask for references you can actually connect with and read the reviews the vendor doesn't link to¹². A vendor that can't produce a single client willing to take your call is a vendor to walk away from.

Then vet security before you grant any access, because the risk of a vendor becoming your weak link is rising fast. In the latest Verizon data, 30 percent of breaches involved a third party, double the 15 percent of the year before¹¹. Ask whether the firm holds SOC 2 or ISO 27001, whether it signs NDAs, and how it isolates client data. If your build touches customer or regulated data, this stops being optional. A short list of questions to put to any shortlist:

• Who exactly will write my code, and can I see their CVs or LinkedIn profiles?
• Can you connect me with two clients on builds like mine?
• What does your security posture look like, and will you sign an NDA?
• How do you handle scope changes, and are they re-quoted in writing?
• Do the code, repositories, and IP transfer to me, and exactly when?

The 2026 rate landscape, triangulated across agency guides, marketplace data, and freelance surveys, looks roughly like this^15161718:

The rate gaps trace back to a labor-cost gap that's genuinely enormous. In Stack Overflow's 2025 survey of nearly 24,000 developers across 177 countries, the median back-end salary was about $175,000 in the US, roughly $87,000 in Germany, and $22,086 in India¹⁴. That spread is the real reason offshore teams can quote 40 to 70 percent below US and Western European rates¹⁸. It's also why an agency hour costs more than a freelance hour: agencies bill two to four times a developer's actual cost to cover management, QA, overhead, and margin².

So how to choose. Freelancers are cheapest and undercut small agencies by roughly $40 to $85 an hour, but you get limited bandwidth, narrow specialization, and little legal recourse if a build goes sideways¹⁷. Agencies cost more but own the whole delivery, from scoping to QA to handover. Offshore and nearshore teams can be excellent value, but the headline rate is a weak proxy for total cost: once you add coordination, time-zone drag, QA, and any rework, the gap between a cheap hour and an expensive one narrows¹⁸. Judge the fixed quote and the shipped result against each other, not rate against rate. Our custom software development services page covers how we scope and quote a build end to end.

Start with the evidence, because it genuinely cuts both ways and any vendor claiming AI simply makes everything faster is overselling. The two most-cited controlled studies point in opposite directions:

A GitHub study found developers completed a self-contained, greenfield task about 56 percent faster with Copilot²³. A 2025 METR study of experienced developers working on large, mature repositories found they were 19 percent slower with early-2025 AI tools, even though they felt faster²⁴. Both are true. AI compresses simple, new, well-scoped work and struggles on gnarly existing systems, and a vendor worth hiring can tell you which kind of work yours is.

The bigger reasons to ask hard questions are security and ownership. In Veracode's 2025 testing, 45 percent of AI-generated code introduced a vulnerability from the OWASP Top 10, rising to 72 percent in Java, with no improvement in newer models²⁸. And the US Copyright Office has been explicit that purely AI-generated code isn't copyrightable, because writing prompts alone doesn't confer human authorship, which means the AI-written portions of your deliverable may not be protectable intellectual property at all²⁹³⁰. Developers themselves are wary: adoption is near-universal at 84 percent, but 66 percent say they lose time fixing AI output that's almost right, and more distrust the accuracy of AI answers than trust it (46 percent versus 33 percent)²⁵. Directional signals from GitClear and Google's DORA program point the same way, with copy-pasted code rising sharply and measures of delivery stability slipping as AI adoption climbs²⁷²⁶.

So put five questions to any vendor that leans on AI:

• What share of the code is AI-assisted, and how is it reviewed and tested?
• Do you run security scanning on AI-written code, and who owns the vulnerabilities it introduces?
• Is our proprietary code or data ever sent to a third-party AI service, or used to train one?
• Who owns the delivered code, are the AI-generated portions protectable, and will you indemnify us?
• If AI speeds you up, how does that show up in the price or the timeline?

The failure data is grim and remarkably consistent across decades of research:

The Standish Group's CHAOS research classed only 29 percent of projects as successful, with 52 percent challenged and 19 percent failed outright, though it's an industry survey rather than an audited study, so read it as directional¹⁹. McKinsey and the University of Oxford, studying 5,400 large IT projects, found an average 45 percent budget overrun, 7 percent time overrun, and 56 percent less value than predicted, with one in six turning into a runaway that threatened the business²⁰. Flyvbjerg and Budzier, looking at 1,471 projects, found a 27 percent average cost overrun and the same one-in-six pattern of "black swan" blowups running roughly 200 percent over budget²¹.

Notice those big numbers describe large, enterprise-scale projects, not a small business build. The useful takeaway isn't the size of the disasters, it's their cause. As far back as 2011, 75 percent of executives expected their projects to fail from the start, 80 percent of teams spent at least half their time on rework, and 78 percent felt the business was out of sync with requirements²². The through-line is loose requirements and no accountability for the outcome. The structural fix is the opposite of a big-bang build: break the work into small, milestone-billed increments, put an acceptance gate on each one, cap the exposure, and re-quote any new scope in writing before it enters the build. That's not motivational advice; it's how you stop being a statistic.

Our model is built around the protections in this guide. You send a few sentences about what you want, and within 48 business hours we reply with a written scope, a milestone breakdown, and a fixed quote, so you know your number before spending anything. A small start fee from $499 locks in the work. You pay for each milestone when it ships and works, the final payment waits for your sign-off, and on that final payment the code, the repositories, and the IP become yours outright, in your name, with no license and no lock-in. If you want the mechanics, our custom software build methodology and our custom software development services page lay them out.

If you already know it's a web app or a mobile app, our web app development and mobile app development pages cover the specifics of each. If you're still sizing the budget, our companion guide on how much custom software costs breaks down the bands, and the full guides library covers the rest.