Handing Your Product's Software to Someone Else

Hardware companies outsource software far more often than the reverse, usually for the same reason: the founders can explain a mechanism in detail and go quiet when asked what the cloud backend should look like. Outsourcing is a perfectly good answer. What goes wrong is rarely the decision itself and almost always the terms around it — specifically, that eighteen months later the company owns a working system nobody left in the building can modify. Here is how to outsource product software and end up owning an asset rather than a dependency.

When outsourcing is the right call

Outsource when the work is bounded, when you need a skill you will not need permanently, or when speed matters more than building capability. A firmware team that needs a mobile app once, a device that needs a backend built and then mostly left alone, an integration with a customer's ERP — all good candidates.

Keep it in-house when the software is the product's competitive advantage, when requirements will change constantly, or when the system will need continuous work for years. The tradeoff is laid out more fully in outsourcing product development versus building an in-house team, and the honest summary is that outsourcing converts a hiring problem into a management problem. It does not remove the need for someone on your side who understands what is being built.

Every successful outsourcing arrangement has a technically literate owner on the client side — a CTO, a contract architect, or a fractional technical lead — who can read a pull request, challenge an estimate, and tell whether "almost done" means anything. Without that person, you are buying invoices.

Onshore, nearshore, offshore

The rate difference is real but smaller than it looks once you account for management overhead, rework, and your own time spent clarifying. A useful rule: the further the time zone, the more the specification has to carry, because every ambiguity costs a full day instead of a hallway conversation. If requirements are still forming, distance is expensive regardless of hourly rate.

Hardware changes the calculation too. A backend can be built anywhere; an app that talks to your device over Bluetooth cannot be debugged by someone without the device on their desk. Shipping units through customs is a real line item, and one reason the hardware-adjacent parts of the stack often stay closer to home.

Fixed price or time and materials

Both models work; each fails in a specific way.

Fixed price transfers risk to the vendor, and vendors price risk. Expect a premium of 20 to 40 percent over the honest estimate, plus an incentive to do exactly what the contract says and nothing more. Every clarification becomes a change order. It suits well-defined, self-contained pieces — a firmware driver, a defined integration — and fails on anything exploratory. A fixed price is only as good as the specification behind it, and writing that specification is itself a paid engagement.

Time and materials is honest about uncertainty and gives you the flexibility to change direction, which you will. Its failure mode is a project with no natural end, because nobody is penalized for taking longer. Control it with a not-to-exceed ceiling per phase, two-week increments with reviewable output, and the right to stop at any increment boundary.

A hybrid works well for most product software: a small fixed-price discovery phase producing an architecture and estimate, then time and materials with phase caps for the build. The same reasoning applies across engineering disciplines and is covered in fixed price versus time and materials for a development project.

Ownership: code, IP, and accounts

This is the section that saves companies. In the United States, work created by an independent contractor does not automatically belong to you — copyright vests with the author unless there is a written assignment. "Work for hire" language alone is not sufficient for most software. You need an explicit, signed assignment of all rights, covering the vendor's employees and any subcontractors they use. Read who owns the IP a contractor creates for you before signing.

Then go beyond the IP clause to the practical infrastructure, because owning the copyright to code you cannot access is not ownership:

• Repositories in your organization. Your GitHub, GitLab, or equivalent account, from the first commit. The vendor gets access; they do not host it.
• Cloud accounts in your name. Your AWS or Azure account, your billing, your root credentials; vendors get scoped access. Migrating production out of a vendor's account later is expensive and risky.
• Domains, certificates, app store accounts, and signing keys registered to your company. Losing an app signing key means users cannot receive updates.
• Third-party licenses documented. A copyleft library discovered during due diligence is a genuine problem.
• No vendor-proprietary frameworks without a perpetual license in writing. Some shops build on internal frameworks precisely to make leaving hard.

Preventing a codebase nobody else can maintain

The most expensive outsourcing failure is not overspend. It is inheriting a system that works but is undocumented, untested, and structured in a way only the original team understands. Once that team is gone, every small change becomes archaeology and the eventual answer is a rewrite. Prevent it with contract requirements, not good intentions:

1. Continuous integration from week one, running in your account. If the build only works on one developer's laptop, you do not have a deliverable.
2. A README a new engineer can follow to a running system on a clean machine — tested by actually having someone do it, mid-project rather than at the end.
3. Automated tests with an agreed scope on the paths that matter, running on every merge.
4. Code review by someone on your side, or an independent reviewer hired for a few hours a month. This single measure catches most quality drift.
5. Architecture documentation — a diagram, the data model, the deployment topology, and the decisions with their reasons — version-controlled alongside the code, as in engineering documentation and version control.
6. Deployment that is not a person. A scripted path to production, with separate staging and production environments so releases are rehearsed rather than improvised.
7. Standard, boring technology. Push back on exotic choices; you need to be able to hire someone else who knows it.

Handover and what comes after

Write the handover into the contract at the start; negotiating it at the end gives the vendor all the leverage. A real handover includes a working build from a clean checkout, credential transfer, a recorded architecture walkthrough, a documented backlog of known issues, and a support window — typically 30 to 90 days — during which the original team answers questions at an agreed rate. Tie final payment to it, and pair it with acceptance testing and project handover criteria agreed before the build starts.

Then budget for the software's life after the vendor. Connected product software is never finished: certificates expire, dependencies need security patches, cloud services deprecate APIs, phone platforms change annually. Ongoing spend of 15 to 25 percent of the original build cost per year is normal, broken down in annual software maintenance cost for a connected product. Decide before the project ends whether that work goes back to the same vendor, to a new one, or in-house — and keep the codebase in a state where all three remain possible.

Projects House builds the software side of physical products — firmware, apps, and backends — with the documentation, repositories, and handover discipline that keep the result maintainable by whoever comes next. If you are deciding how to get your product's software built, tell us about it through the contact form.