Short answer: pick an engagement model that matches how well you can define the scope, sign a contract that assigns IP to you and ties payments to accepted milestones, keep every account in your company's name, and insist on seeing working software every one to two weeks. Most outsourcing failures trace back to one of those four being absent.
Not legal advice. This guide explains what contracts for outsourced development usually cover so you can have an informed conversation with a lawyer. It is not a substitute for one. BBR is a studio that takes outsourced projects, so we describe the process from the vendor's side of the table as well as yours.
Engagement models
| Fixed price | Time and materials | Dedicated team | |
|---|---|---|---|
| How it works | A set price for a written scope, paid by milestone | You pay for hours worked at agreed rates, usually invoiced monthly | A fixed group of people works only on your product for a monthly fee |
| Best for | First releases and projects with a clear definition of done | Exploratory work, evolving products, maintenance | Continuous development over many months |
| Who carries the estimate risk | Mostly the vendor, who prices in a margin for it | Mostly you | Shared: cost is fixed, output varies |
| Flexibility | Low; changes go through change requests | High | High within the team's capacity |
| Budget predictability | High | Low unless capped | High per month, open-ended overall |
| Your involvement | Heavy up front (scope), lighter during the build | Continuous prioritization | Continuous; you act as product owner |
| What to watch | Vague scope leads to disputes; vendor may resist any change | Costs drift without a budget cap and regular reporting | Paying for idle capacity when the roadmap is thin |
Two hybrids are worth knowing. Paid discovery followed by fixed price gives the vendor enough information to quote accurately and gives you a scope document you own, whichever vendor you then choose. Time and materials with a cap keeps flexibility while limiting exposure: the vendor must flag when a set percentage of the budget is used.
A team on a monthly basis is what BBR calls product engineering; project work is described under mobile app development and SaaS development.
Contract essentials
Most engagements use a master services agreement for the legal terms plus a statement of work for the specific project. Whatever the format, check that these points are covered.
IP assignment
The agreement should assign ownership of all work created for the project (source code, designs, documentation) to your company, and say when: commonly on payment of each milestone or on final payment. It should separately list any pre-existing vendor code and grant you a perpetual licence to use and modify it, and acknowledge that open-source components remain under their own licences. If subcontractors are involved, the vendor should warrant that they have assigned their rights too.
Confidentiality
A mutual NDA, either standalone before detailed discussions or as a clause in the main agreement. It should cover your business information, your users' data and the fact of the project if that matters to you.
Scope and acceptance criteria
The statement of work lists features with testable acceptance criteria. "User can reset password by email link; link expires after one hour" can be accepted or rejected. "Secure login" cannot. The contract should also describe the acceptance procedure: how long you have to review a milestone, how defects are reported, and what happens if you do not respond.
Payment milestones
Payments are tied to deliverables you can inspect, for example:
| Milestone | What you can verify | Illustrative share |
|---|---|---|
| Signing | Team reserved, kickoff scheduled | 15–25% |
| Design approved | Clickable prototype of the core flows | 15–20% |
| First feature set on staging | You can log in and complete the core workflow | 20–25% |
| Feature complete on staging | All acceptance criteria demonstrable | 20–25% |
| Launch and handover | Live in production or stores; repository and documentation delivered | 15–20% |
The percentages are an example of a balanced structure, not a standard. The principle is that neither side is ever far ahead of the other.
Change requests
A written procedure: the change is described, estimated, and approved by you before work starts, with its effect on price and schedule stated.
Warranty period
A defined period after delivery during which defects against the agreed scope are fixed without charge. The clause should define a defect (behavior that contradicts the acceptance criteria) as distinct from a change (behavior you now want to be different).
Termination and handover
Either side can end the engagement with notice. On termination you pay for accepted work and work in progress, and receive all code and materials produced to date. This clause is what makes "no lock-in" real.
Data protection
If the vendor will handle personal data about your users, privacy law in your users' location may require specific contract terms, such as a data processing agreement under GDPR or UK GDPR. Minimizing vendor access to real data reduces this burden. Ask your lawyer what applies.
Liability, governing law and disputes
These clauses decide what happens when things go badly wrong: caps on liability, which country's law applies, and where disputes are resolved. They are negotiable and they are squarely lawyer territory.
Accounts and access: the practical side of ownership
A contract says you own the product. Account ownership means you can actually operate it. Set these up in your company's name before development starts and grant the vendor access:
- Source code repository (for example a GitHub organization)
- Cloud hosting and database accounts
- Domain registrar and DNS
- Apple Developer Program and Google Play Console accounts
- Payment processor, email, SMS, analytics and other third-party services
- A company-owned password manager for shared credentials
Store accounts deserve particular attention. An app published under a vendor's developer account has to be transferred later, which takes effort and coordination. Publishing under your own account from the start avoids the problem. Enrollment for an organization can take some time, so begin early.
Time zones and communication
- Agree an overlap window. Two to three shared working hours a day is enough. Put recurring calls inside it.
- Default to writing. A weekly written update covering done, next, blocked and budget used. Decisions are recorded in the tracker, not left in call memories.
- One channel, one contact. A shared chat channel for daily questions and a single named person responsible for answering.
- A fixed demo rhythm. Every one or two weeks, on a staging environment you can open yourself afterwards.
- A decision-maker on your side. One person with authority to answer product questions within a day. Slow client decisions are one of the most common causes of delay.
- Use the offset. With a team ahead of your time zone, feedback you send in your afternoon can be addressed by your next morning.
Risks and how to reduce each
| Risk | How it shows up | Mitigation |
|---|---|---|
| Misunderstood scope | The delivered feature matches the vendor's reading, not yours | Acceptance criteria; clickable prototype approved before the build; early demos |
| Cost overrun | Change requests pile up, or hours drift | Fixed price with a contingency you hold back, or a capped budget with weekly burn reports |
| Poor code quality | It works in the demo and is hard to change later | Conventional stack; code review; an independent engineer auditing the repository at a midpoint milestone |
| Vendor disappears or fails | Communication slows, then stops | Code pushed to your repository continuously; accounts in your name; milestone payments so you never prepay far ahead |
| Lock-in | Proprietary platform, or only the vendor knows how to deploy | Licence for pre-existing components; deployment documented; handover clause |
| IP dispute | Ambiguity over who owns what | Written assignment, subcontractor warranty, open-source list |
| Confidentiality or data leak | Real user data on developer machines | NDA; synthetic test data; least-privilege access; revoke access at the end |
| Communication gaps | Surprises at the deadline | Written weekly updates, fixed demo rhythm, named contact |
| Store rejection or launch delays | The app is finished but not live | Vendor with store release experience; review guidelines checked at design stage; time for review in the schedule |
| Key-person dependency | One engineer holds all the knowledge | Documentation as a deliverable; more than one person familiar with the code |
Step by step: from brief to signed contract
- Write a one-page brief. Users, core job, first-release features, platforms, integrations, deadline, budget range.
- Decide what kind of partner you need. See agency or freelancer if unsure.
- Build a longlist of five to eight from referrals, directories and search, then cut to three to five by looking at shipped work relevant to yours.
- Sign NDAs if your idea or data requires it, and send the same brief to each.
- Hold an intro call with each. Note who asks good questions about your users and who goes straight to price.
- Request written proposals with line-item scope, exclusions, team, timeline, pricing model and payment schedule.
- Compare scopes, not totals. Put the proposals side by side and mark what each one omits.
- Run due diligence on the top two. Use the agency due-diligence questions, try their shipped products, speak to references where available.
- Consider a paid discovery phase with your first choice. It produces the detailed scope, tests the working relationship at low cost, and the output is yours.
- Negotiate the contract covering the essentials above, with your lawyer reviewing.
- Create the accounts in your company's name and grant access.
- Sign, pay the first milestone and hold the kickoff. Agree the communication rhythm in that first meeting.
For budgeting the build itself, see the guides to what an app costs to build and SaaS development cost. How BBR handles ownership, NDAs, change requests and handover is set out on the how we work page, and the broader service is described under custom software development.