App Development Outsourcing: Running an External Team Well

Most writing about outsourcing addresses the selection decision. The harder problem is governance: how a company that does not build software manages an external function that does, over years rather than months, without losing control of its own product.

Companies that outsource successfully are not the ones that chose the best vendor. They are the ones that kept four things in-house.

The four capabilities you cannot outsource

Product decisions. What to build and in what order. A vendor can advise and should, and if they are choosing your roadmap you have outsourced your business rather than your engineering.

Technical judgement, at least at review level. Somebody on your side has to be able to assess whether an architectural decision is reasonable. This does not require a full-time CTO. A fractional technical advisor at a few hours a month, costing $1,000 to $4,000, is the highest-return spend available to a non-technical company outsourcing development.

Knowledge of your own system. Architecture documentation, data model, integration inventory, and deployment process, held by you and readable by a team that has never seen it. Without this you are dependent rather than outsourced.

Access and ownership. Repository, cloud accounts, domain, developer accounts, and third-party service accounts, all in your name with vendors added as users. This is the single most consequential governance decision and it costs nothing to get right at the start.

Contract terms that determine how much control you keep

Seven, and the first four are where dependency is created or avoided.

IP assignment on payment, explicit and covering code, designs, and documentation.

Continuous commits to your repository, not delivery at milestones. Code that lives on a vendor's infrastructure until payment is leverage against you.

Infrastructure under your accounts, with the vendor as a user whose access can be revoked in an afternoon.

Documentation as a named deliverable with acceptance criteria, not a promise. Undocumented systems are how a vendor becomes irreplaceable without anyone deciding it.

A defined exit, covering notice period, handover contents, transition support, and what happens to work in progress. Negotiate this while everyone is optimistic.

Named individuals with allocation percentages and notice before substitution. Undisclosed substitution mid-project is the most frequent complaint in ongoing engagements.

Acceptance criteria per deliverable, so that finished has a definition and a final holdback is enforceable.

Bolder Apps prices project work fixed-scope rather than hourly and sells maintenance and staff augmentation alongside project work. Whichever vendors you use, the terms above matter more than the model, because they determine whether you are buying capacity or accumulating dependency.

‍

‍

Governance rhythm for an ongoing engagement

Project management differs from vendor management, and companies that outsource for years need both.

Weekly, at project level: a standing slot for decisions rather than status, and a testable build every one to two weeks. Fortnightly builds are the mechanism through which you verify progress rather than hearing about it.

Monthly, at delivery level: review of what shipped against what was planned, defect trends, and any change requests with their cost. Also a look at spend against budget, which under hourly or retainer models drifts quietly.

Quarterly, at relationship level: a conversation with whoever owns the relationship above your project manager. Team composition, upcoming capacity, technical debt accumulating, and whether the arrangement still fits. This is the meeting that prevents a slow decline nobody escalates.

Annually: an independent review of the codebase. Not an accusation. A vendor whose work has never been examined by anyone else has no external quality pressure, and the review protects both sides by making quality visible.

In practice, the failure mode of long outsourcing relationships is not poor work. It is gradual dependency: undocumented decisions, credentials only the vendor holds, and knowledge that exists only in their team. That accumulates invisibly and is discovered at exactly the moment you want to change something.

Single vendor or several

For most companies below a certain size, a single vendor plus one internal technical person is the right structure. Multiple vendors on the same codebase creates accountability gaps that consume more management time than the redundancy is worth, and multiple vendors on separate systems only works if the boundaries between those systems are genuinely clean.

What is worth avoiding in every configuration is a vendor who holds the only copy of anything.

Knowledge retention in practice

Four artefacts, kept current, that make a vendor replaceable without making them adversarial.

An architecture overview readable by an engineer who has never seen the system: what the components are, what they do, and how they communicate. Two pages beats forty.

A decision log recording significant technical choices and why they were made. This is the artefact whose absence causes the most expensive confusion later, because a successor team cannot distinguish a deliberate decision from an accident.

An integration inventory listing every external system, what it is used for, who holds the credentials, and what breaks if it fails.

A runbook covering deployment, rollback, backup restoration, and what to do in an incident. Test the backup restoration at least once, because an untested backup is a hypothesis.

Require these as deliverables with acceptance criteria rather than requesting them. Documentation asked for politely at the end of a project does not arrive.

‍

‍

Cost governance

Outsourced engineering spend drifts, and three practices prevent it.

Under any hourly or retainer arrangement, require time reporting by person and by task, detailed enough to audit. A monthly total is a bill rather than a report.

Track cost per shipped increment over time. Rising cost for comparable output usually means accumulating technical debt or declining team quality, and it is visible in the trend long before it is visible in any single month.

Reprice periodically. Not adversarially, and rates and scope agreed two years ago should be examined. A vendor confident in their value will engage with the conversation.

The first ninety days of a new outsourcing relationship

Governance is easiest to establish at the start and very difficult to introduce later.

Week one: access set up in your accounts rather than theirs. Repository, cloud infrastructure, developer accounts, and third-party services, all owned by you with the vendor added as a user. Agree the communication rhythm and name your single decision-maker.

Weeks two to four: confirm the documentation deliverables and their acceptance criteria, and confirm that code is being committed continuously to your repository rather than held. Verify the first testable build arrives on schedule, because the first missed cadence is the one that sets the pattern.

Month two: run the first monthly delivery review comparing what shipped against what was planned, with spend against budget. Establish that this happens as routine rather than as a response to a problem.

Month three: the first relationship-level conversation, and the point at which you should be able to answer four questions yourself. Who specifically is working on this. Where does the code live. What would happen if this vendor stopped tomorrow. And is anything undocumented that only they understand.

If any of those four answers is uncomfortable at month three, it will be considerably worse at month eighteen. Bolder Apps prices project work fixed-scope rather than hourly and sells maintenance and staff augmentation alongside it, and the terms worth settling with any vendor at the outset are the same regardless of model: ownership, documentation, and a defined exit.

When to bring development in-house

Three signals, and none of them are dissatisfaction.

Development is continuous rather than project-based, which usually makes in-house cheaper past twelve to eighteen months of sustained work.

Domain knowledge is becoming your advantage. If understanding your customers' workflow deeply is what makes the product good, that knowledge compounding inside your own team is worth more than the flexibility of external capacity.

The product is core to the business and the concentration risk is no longer acceptable.

The transition that works is gradual: hire a lead first, have them work alongside the vendor for a quarter, then hire engineers who inherit a documented codebase. Some firms supply staff augmentation during exactly this transition, which keeps continuity while knowledge transfers rather than evaporating.

Sources

• World Intellectual Property Organization guidance on software IP assignment, wipo.int
• Project Management Institute, PMBOK Guide, on procurement and vendor management
• NIST Special Publication 800-53, on third-party and supply chain risk
• OWASP Application Security Verification Standard, owasp.org
• SOC 2 Trust Services Criteria on vendor management, AICPA