What to outsource and what to keep in-house
Outsourcing works best when you hand over execution while keeping the decisions that define your product. A simple rule: keep anything that requires deep knowledge of your customers or strategy, and outsource work that can be specified, reviewed and accepted.
| Usually keep in-house | Often outsourced | Either, depending on maturity |
|---|---|---|
| Product vision and roadmap | Feature development against a groomed backlog | UX research and design |
| Backlog prioritization and acceptance | QA, test automation and device testing | Architecture and technical leadership |
| Ownership of accounts, code and data | Release management and store submissions | Backend and API development |
| Customer relationships and support escalation | OS updates and routine maintenance | DevOps and infrastructure |
Writing a brief or RFP vendors can actually quote
A weak brief produces quotes you cannot compare. A good one is short, specific and honest about what you do not know yet.
- 1
Business context
Who the users are, what problem the app solves, how success will be measured and any hard deadlines such as a launch event or contract date.
- 2
Scope
Must-have features for the first release, nice-to-haves, and explicit exclusions. User stories or a simple feature list both work.
- 3
Technical constraints
Target platforms and OS versions, existing systems and APIs, preferred stack if any, hosting requirements and data residency rules.
- 4
Non-functional requirements
Performance, accessibility, security, offline behavior and any regulatory obligations such as HIPAA or GDPR.
- 5
Commercial details
Budget range if you have one, preferred engagement model, required overlap hours and the format you want proposals in.
Asking every vendor to price the same phases, using the same template, makes comparison far easier. Our article on reading an app development quote lists the line items to request.
A vendor evaluation scorecard
Score each shortlisted vendor from 1 to 5 on every criterion, multiply by the weight, and add up the total. Adjust the weights to match your priorities; a regulated healthcare app might weight security much higher than this example.
| Criterion | Example weight | What evidence to look for |
|---|---|---|
| Relevant mobile experience | 20% | Apps you can install, similar complexity, references you can call |
| Engineering practices | 20% | Code review, automated tests, CI/CD, sample code quality |
| Team and seniority | 15% | Named people, interviews, retention and replacement terms |
| Communication | 15% | Response quality during the sales process, proposed rituals, overlap hours |
| Security and data handling | 10% | Access control, device policy, how credentials and client data are protected |
| Commercial clarity | 10% | Itemized pricing, clear assumptions and change process |
| Contract terms | 10% | IP assignment, warranty, termination and handover obligations |
A paid discovery phase or short trial sprint with your top one or two vendors is the best tie-breaker. You learn more from two weeks of real collaboration than from any proposal document.
Choosing a contract type
The contract type decides who carries the risk of change. The three most common options in mobile app development outsourcing are summarized below; our dedicated page on fixed price, T&M and team models compares them in more depth.
Fixed price
Suits small, stable scopes. Gives budget certainty but makes change formal and often expensive.
Time and materials
You pay for hours worked. Flexible and transparent, but you need to manage scope and budget actively.
Dedicated team
A stable squad billed monthly. Good for ongoing product work where priorities evolve.
Whatever the model, the agreement should cover a master services agreement with statements of work beneath it, IP assignment, confidentiality, data protection, warranty, termination rights and handover duties.
Governance: how to steer an outsourced project
Meeting rhythm
- Daily stand-up in the overlap window, kept short and focused on blockers.
- Sprint review and demo every one or two weeks, with a working build you can install.
- Monthly steering meeting with sponsors on both sides to review budget, risks, roadmap and staffing.
- Quarterly retrospective on the relationship itself: what to keep, change or stop.
KPIs worth tracking
Metrics should start conversations, not punish teams. Agree definitions together and watch trends rather than single values.
- Velocity: the amount of estimated work completed per sprint. Useful for forecasting when it is stable; misleading if compared across teams or used as a target.
- Defect escape rate: the share of defects found after release rather than during testing. A rising trend suggests QA coverage or definition of done needs work.
- Cycle time: how long a task takes from starting work to being released. Long cycle times often point to slow reviews or unclear requirements.
- Crash-free sessions: a production stability signal from your crash-reporting tool.
- Budget burn vs plan: actual spend against forecast, reviewed at each steering meeting.
Managing handover and code ownership
Plan the exit on day one, even if you never use it. Clean ownership protects you if the vendor relationship ends, if you bring work in-house or if you are acquired and face technical due diligence.
- 1
Own every account
Source repositories, cloud projects, App Store Connect, Google Play Console, analytics and crash reporting should all be registered to your organization, with the vendor invited as users.
- 2
Keep documentation current
Architecture notes, environment setup, release steps and third-party credentials stored in your password manager, not in someone's inbox.
- 3
Require reproducible builds
Anyone with access should be able to build and release the app from the repository using documented steps and CI.
- 4
Schedule an overlap period
When transitioning to an in-house or new team, budget a few weeks where both teams work together on real tickets.
If you are inheriting an app that lacks this hygiene, an app modernization effort can stabilize the codebase before further feature work.
Common outsourcing pitfalls
- Choosing purely on price, then paying the difference in rework and missed deadlines.
- No single product owner, so the vendor receives conflicting instructions.
- Accepting status reports instead of installable builds.
- Leaving maintenance out of the plan, then scrambling when the next OS release breaks something. Our maintenance and support page outlines what ongoing care involves.
- Treating the vendor as a ticket factory and withholding product context they need to make good decisions.
Next steps
Start with a one-page brief, a shortlist of three to five vendors and a scorecard agreed with your stakeholders. If you would like a second opinion on your brief or a quote to compare against, send us your requirements and we will respond with questions, assumptions and a phased estimate.