The short answer
Fixed price works best for a clearly scoped first version: you know the number before work starts. Hourly or time-and-materials works best when the scope is genuinely unknown. A monthly retainer works best after launch, when you need steady improvements rather than one project.
Whichever model you pick, the contract matters more than the model. This guide explains each one, the traps to avoid, and a checklist of clauses every Indian founder should see in writing before paying an advance.
The three ways app projects are priced
| Model | How it works | Works well when | Watch out for |
|---|---|---|---|
| Fixed price | One agreed price for an agreed scope, paid in milestones | The first version is clear: sides, screens, integrations | Vague scope that turns every question into a “change request” |
| Hourly / time and materials | You pay for hours or days worked, usually monthly | Research, prototypes, or adding to an existing codebase | No ceiling; you carry the risk of slow work |
| Monthly retainer | A set team for a set monthly fee | After launch: steady features, fixes and upkeep | Paying for idle time if you have no clear backlog |
At The Saral, we use the same pattern: a fixed quote for a concept sprint or a full product build, and a monthly “studio on call” arrangement after launch that you can pause or stop any month.
When fixed price is the right call
Fixed price protects you when you can describe what you want. You know your budget, the team carries the risk of their own estimate, and everyone has the same finish line.
- You can list the user types: customer, partner, admin.
- You can name the main flows: browse, book, pay, track, refund.
- You know the integrations: payment gateway, maps, SMS or WhatsApp, accounting software.
- You accept that new ideas mid-build become a short, priced change, not free extras.
If you can't answer those yet, don't force a fixed price on the whole build. Do a short fixed-price discovery or concept sprint first. Two weeks of work that ends in a clickable prototype and a clear scope is the cheapest way to get an honest fixed quote for the rest. Our MVP guide shows how to scope it.
When hourly makes more sense
Hourly billing is honest when nobody can see the end yet.
- You are inheriting an existing app and don't know what state the code is in.
- You need research or experiments before choosing a direction.
- You want a few days of help each month on an app your own team runs.
If you go hourly, ask for a weekly report of hours against tasks, a monthly cap you approve in advance, and the right to stop at any time with all work handed over.
Milestones and payment schedules that protect both sides
In India, an advance is normal. What matters is what each payment buys. Tie payments to things you can see and use, not to dates or percentages of effort.
| Milestone | What you should be able to see |
|---|---|
| Signing / advance | Agreed scope document, timeline and team |
| Design approval | Clickable designs for every main screen on every side |
| First working build | Core flows running on a test link or test app on your own phone |
| Feature complete | Every scoped feature working with realistic data |
| Launch and hand-over | Apps in the stores or live on your domain; code, designs and access handed over |
Ask for a demo link you can open every week. If you only see the product at the end, you only find problems at the end.
Clauses to check before you sign
- Ownership. Source code, design files, brand assets and accounts become yours on payment. Not licensed, not held back.
- Accounts in your name. Play Console, App Store, cloud hosting, domain and payment gateway should be registered to your business from the start.
- Scope document. Screens, flows, user types and integrations listed. “Similar to” is not a scope.
- Change process. How a new request is estimated, approved and priced before work begins.
- Acceptance. How you test and sign off each milestone, and how long you have to do it.
- Bug fixing after launch. A warranty period for defects in the agreed scope, separate from new features.
- Confidentiality. An NDA, ideally before you share the full idea. We sign one before the first call if you like.
- Exit. What happens to code and payments if either side stops early.
- GST. Whether quoted prices include GST, and invoicing that your CA is happy with.
This is practical guidance, not legal advice. For a large project, have a lawyer review the contract, especially ownership, liability and exit clauses.
Red flags in a quote
- A single number with no breakdown of sides, screens or integrations.
- Very low prices that assume a template the quote never mentions.
- Code or app store accounts held in the developer's name “for convenience”.
- No working build until the final payment.
- Monthly fees to “license” the app you paid to build.
- Promises of downloads, rankings or revenue. No honest team can guarantee those.
For a fuller checklist, read how to choose an app development company in India.
After launch: the retainer question
An app is never finished. Phones update, store rules change, customers ask for things. Budget for upkeep from the start; our maintenance cost guide explains what it usually covers.
A retainer works when you have a backlog: a list of improvements ranked by value. Without one, a smaller support plan for fixes and updates is often enough. Either way, keep the option to stop, and keep everything in your own accounts so you can move to another team or hire in-house.
Scope examples by type of product
The scope document is where fixed-price projects succeed or fail. It helps to see what a complete scope covers for common products.
- A [food delivery app](/solutions/food-delivery-app): customer app, restaurant screen, rider app and ops dashboard; menus, cart, UPI and COD, live tracking, refunds and payouts.
- A [business website](/solutions/business-website): page list, contact or booking forms, CMS for your team, speed and SEO basics, hosting on your account.
- A [marketplace app](/solutions/marketplace-app): buyer and seller flows, chat, trust and safety, moderation console, and whether you take payments.
If a scope document lists screens but not the user types, integrations and admin tools, it is incomplete. The app cost guide explains which of these move the price most.
When you're ready, send a four-tap brief. We read it, walk you through the builds closest to yours on a 30-minute call, and send a fixed quote with scope and timeline in writing within 48 hours.
Questions people ask
Is a fixed-price app project better than hourly?
For a clearly scoped first version, usually yes: you know the cost upfront and the team carries the risk of its estimate. Hourly is better when the scope is unknown, such as research or work on an inherited codebase. Many founders combine them: a short fixed-price sprint to define scope, then a fixed price for the build.
How much advance should I pay an app developer?
An advance is common in India, but tie it and every later payment to something you can see: a signed scope, approved designs, a working build. Avoid paying most of the money before you see working software. Exact percentages vary by team and project size, so compare what each payment buys, not just the number.
Who should own the source code of my app?
You should. The contract should say that source code, design files and brand assets transfer to you on payment, and that app store, hosting and domain accounts are in your business's name. At The Saral, code, designs and brand assets are handed over in full, in tools your team can keep using.
What counts as a change request?
Anything outside the agreed scope document: a new user type, a new integration, a different flow. Small clarifications inside the scope shouldn't be charged. A fair contract explains how changes are estimated, approved and priced before work begins, so you decide whether each one is worth it.
