Two quotes land in your inbox for the same app. One is a single number for the whole build. The other is an hourly rate with an estimate range attached and a note saying "final cost depends on scope changes". They look like two prices. They're two different allocations of risk, and the fixed price vs hourly offshore development decision is mostly about who carries that risk when the plan turns out to be wrong. Because the plan always turns out to be at least a little wrong.
Fixed price vs hourly offshore development: what each model actually means
Hourly (time and materials): you pay for the hours the team works. The vendor gives an estimate, but you carry the risk if it takes longer. You also keep full flexibility: change direction on Tuesday and nobody needs to renegotiate.
Fixed price: the vendor commits to delivering a defined scope for an agreed amount. If it takes longer, that's their problem. In exchange, the scope has to be written down precisely, and changes go through a change request.
Neither is a scam and neither is safe by default. Each fails in a predictable way, and the right choice depends on how well you understand what you're building.
How hourly goes wrong offshore
Hourly billing works well when you can see the work and direct it every day. Offshore, with a time difference and possibly a language gap, you often can't. The common failure looks like this:
- Timesheets arrive every two weeks. They say "API integration, 38 hours" and you have no way to judge whether that's right.
- The estimate was for a version of the product that was never written down, so every overrun can be explained as a scope change.
- Nobody has an incentive to finish. A slow team on hourly earns more than a fast one.
None of this requires a dishonest vendor. It only requires a vague brief and a client who isn't technical enough to read the commit history. If you are technical and you're adding engineers to your own team, hourly or monthly billing is often the right call, because you're directing the work yourself.
How fixed price goes wrong offshore
Fixed price fails differently. A vendor who quotes a fixed number after one call is guessing, and they protect themselves in one of three ways:
- Padding. The number includes a large buffer you pay whether or not it's needed.
- Thin scope. The written scope is vague in exactly the places that matter ("user authentication", "payment integration"), and every real requirement becomes a paid change request.
- Corner cutting. When the budget runs low, testing, error handling and documentation are the first things to go. You find out after launch.
The fix isn't to avoid fixed price. It's to make the scope precise enough that the price means something. "Payment integration" is not a scope. "Card and UPI checkout through one gateway, webhook verification, handling duplicate webhooks, refunds from the admin panel, a reconciliation report" is. If a quote doesn't include that level of detail, read our notes on what an app development quote should include.
The middle option: fixed-price milestones
This is how we work at orithLabs, and it's what we'd suggest to most non-technical founders hiring offshore. The project is scoped and priced before any code is written, then split into milestones. Each milestone has its own fixed price and ends in something you can run: a TestFlight build, a staging URL, a payment flow that takes a test transaction.
Why it works better than either pure model:
- Risk is bounded per milestone. If the vendor underestimates, they absorb it. If you change your mind, it only affects the milestones you haven't started.
- You can stop between milestones. If the work isn't good, you leave with the code you've paid for, in your own repository, and owe nothing further.
- Re-scoping is cheap. After milestone two you know far more than you did at the start. The later milestones can be re-scoped with real information instead of guesses.
- Progress is binary. A milestone is either delivered and working or it isn't. No arguing over whether a feature is "80% done".
We've covered the payment side in how to structure a milestone payment schedule.
Which model fits your situation
A blunt rule of thumb:
- You have an engineering lead who'll review code and direct the work daily: hourly or monthly. You're buying capacity, and you can manage it.
- You're a non-technical founder or a product owner without in-house engineers: fixed-price milestones. You need the vendor to own delivery risk because you can't judge hours.
- You don't yet know what you're building: neither, yet. Pay for a short, fixed discovery phase that produces a written scope, a screen list and a technical plan. Then price the build from that.
- Your product is live and needs ongoing fixes and small features: a monthly retainer with a defined response time usually beats both.
Whatever you pick, insist on three things regardless of billing model: the code lives in a repository you own from day one, you get a written update every week, and the people quoting the work are the people doing it.
Questions to put to any offshore vendor
- What exactly is in scope for the first milestone, and what will I be able to test at the end of it?
- How do you handle a change request? Who prices it, and how quickly?
- If I stop after milestone one, what do I walk away with?
- For hourly work: what level of detail is in your timesheets, and can I map hours to pull requests?
- What happens if a milestone takes longer than you estimated?
The answers tell you more than the number at the bottom of the quote.
If you'd like help turning an idea into a scope precise enough to price properly, that's what our product strategy work is for. orithLabs is a small studio in Delhi NCR; we price before we build and you can stop between milestones. A free 15 or 30 minute call is a reasonable place to start.