Why the engagement model matters
Two vendors with identical rates can deliver very different outcomes depending on how the contract is structured. The model shapes incentives: a fixed-price vendor is rewarded for limiting scope, a time-and-materials vendor for transparency and throughput, a dedicated team for long-term product health. Picking the wrong one creates friction even with a good team.
There is no universally best model. The right choice depends on how well defined your scope is, how often priorities change and how much management capacity you have.
Fixed price
The vendor commits to delivering an agreed scope for an agreed price, usually paid against milestones. It is the model procurement teams find easiest to approve.
- Works well for: small apps, clearly specified features, proofs of concept and projects with a firm budget ceiling.
- Downsides: vendors add a risk buffer to the price, scope must be documented in detail up front, and every change becomes a negotiation.
- Watch for: acceptance criteria that are vague enough to dispute, and a low bid that relies on change requests to recover margin.
Time and materials
You pay for the hours actually worked at agreed rates, usually invoiced monthly with timesheets. Scope can evolve sprint by sprint.
- Works well for: products where requirements will be refined through user feedback, and projects following a discovery phase.
- Downsides: no fixed total, so you need active backlog management and regular budget reviews.
- Watch for: missing caps or forecasts. Ask for a not-to-exceed amount per phase and a burn report at every sprint review.
Dedicated team and staff augmentation
Dedicated team
A stable, cross-functional squad (for example, mobile engineers, QA and a team lead) works only on your product and is billed monthly. The vendor handles hiring, HR, equipment and replacements; you set priorities. Read more about how a dedicated offshore squad is typically structured.
Staff augmentation
Individual engineers join your existing team and follow your processes, tools and leadership. You manage them day to day, while the vendor remains the legal employer. It suits companies with strong in-house engineering management that need extra hands or a specific skill, such as adding experienced iOS engineers to a team that is otherwise Android-heavy.
Build-operate-transfer (BOT)
In a BOT arrangement, a provider builds and runs an offshore team or center for you, then transfers the people, processes and sometimes the legal entity to your company at an agreed point. It is aimed at organizations that want a permanent offshore capability without setting it up alone.
- Works well for: enterprises planning a long-term presence with a sizeable team.
- Downsides: long time horizon, significant legal and tax planning, and transfer fees or conditions that must be negotiated carefully.
- Not suited to: single apps, MVPs or companies without the appetite to run an overseas operation after transfer.
Offshore development engagement models compared
| Model | Billing | Who carries scope risk | Your management effort | Flexibility |
|---|---|---|---|---|
| Fixed price | Per milestone | Mostly vendor (priced into the bid) | Low during build, high up front | Low |
| Time and materials | Hours worked | Mostly you | Medium to high | High |
| Dedicated team | Monthly per team member | Shared | Medium | High |
| Staff augmentation | Monthly or hourly per person | You | High | High |
| Build-operate-transfer | Setup, operating and transfer fees | Shared, shifting to you | High over time | Medium |
Pricing structure affects the total as much as the hourly rate. For a breakdown of what sits inside a mobile budget, see our guide to offshore app costs.
How change requests work in each model
Fixed price
A formal change request is raised, the vendor estimates impact on cost and timeline, and both sides sign an amendment before work starts. Expect some delay for each change.
Time and materials
New work is added to the backlog and prioritized in the next sprint. The cost impact appears in the burn rate, so keep forecasts updated.
Dedicated team
Changes are simply reprioritization. Team capacity stays the same; what gets built next changes. Scaling the team up or down usually needs notice.
Staff augmentation
Your own managers redirect work as they would with employees. Changing headcount follows the contract's notice terms.
Build-operate-transfer
Day-to-day changes follow whatever model runs the team; structural changes, such as team size or transfer date, are negotiated at governance level.
Which model fits your stage
- 1
MVP or first release
A short paid discovery, then either fixed price for a tightly scoped MVP or capped time and materials if you expect to learn and adjust. Avoid committing to a large team before you have validated the product.
- 2
Scaling product
A dedicated team usually fits best once you have users, a roadmap and steady demand. It keeps people and context stable as priorities shift.
- 3
Enterprise program
Often a mix: dedicated teams for core products, staff augmentation to fill specific gaps in internal teams, and fixed-price statements of work for well-bounded integrations. BOT becomes relevant only when a permanent offshore center is part of the strategy.
Models can change over time. Many companies start with fixed price, move to time and materials after launch, and settle into a dedicated team. Agree in the contract how you can switch without starting over. Our broader guide to outsourcing mobile projects covers the governance that makes each model work, and our enterprise mobile development page explains how larger programs are usually organized.
Questions to ask before you sign
Whichever model you lean toward, the contract details decide how it behaves in practice. Ask every vendor these questions and get the answers in writing:
- How are estimates produced, and who on the delivery team reviewed them before the proposal was sent?
- What exactly counts as a change, and how quickly will you return an impact estimate?
- What notice is needed to add or remove team members, and is there a minimum commitment?
- If an engineer leaves, how fast is a replacement provided, and who pays for the handover time?
- What reporting will we receive each sprint: burn, velocity, open risks, test results?
- What warranty applies to delivered work, and how are defects found after acceptance handled?
- Under what conditions can either side terminate, and what handover support is included if we do?
Vague answers to these questions are a stronger warning sign than a high rate. A vendor that has thought through change, staffing and exit is usually one that has run long engagements before.