Flutter developer rates in India: what you pay and why

Why this page has no table of rates

The usual page on this topic gives you a table: junior, mid, senior, with a range of rupees against each. Those tables are tempting and they go out of date almost at once. They also mislead, because a rate is not a property of a developer's seniority alone. It is the output of a calculation involving what is included, who is behind it, how the engagement is structured and what the market looks like on the day.

So rather than give you figures to quote back at a vendor, this page gives you a method for reading the rates you are actually offered. The normaliser above takes any quote and converts it to an effective rate per person per day and per hour. Put in two or three quotes and you will see immediately which ones are comparable and which are not.

Hourly, daily, monthly, fixed: what you are being offered

Quotes arrive in different units, and part of the confusion is comparing across them. An hourly rate is common with freelancers and for support work. A daily rate is common for engagements measured in weeks. A monthly retainer reserves capacity. A fixed price is a single figure for a defined scope.

Each moves risk differently. With an hourly or daily rate you pay for time and carry the risk that it takes longer than expected. With a fixed price the vendor carries that risk, and so will build some margin into the figure to cover it. Neither is better. A fixed price is easier to budget for, provided the scope is clear. A time-based arrangement is more flexible, provided you can see progress.

To compare, convert to the same thing: the total you expect to pay, divided by the person-days of work. The normaliser does this when you give it the total, the weeks and the number of people.

What is inside a rate

People think of a rate as the developer's pay. It is not. It carries a developer's time, and the other time that does not show up in the hours: finding and scoping the work, communicating with you, managing the project, handling the inevitable disruptions. It carries tools and licences, equipment, an office or a home workspace, and the cost of the weeks between projects. It carries a margin for the risk the vendor takes, and the profit that keeps the business alive.

A solo developer has less of this overhead than a company. A company has more layers and so more cost between you and the person coding, but it also has resilience and breadth. A higher rate may buy you things you need. A lower rate may be perfectly good value. The question is always what is included.

• Design: is a designer's time in the figure, or is it your job to supply designs?
• Testing: how many devices, how much, by whom?
• Project management: is someone responsible for keeping the plan?
• Store submission: is it included, and under whose accounts?
• Fixes after launch: how long, and how many?
• Documentation and handover: included or extra?

Why Flutter rates vary so widely

Flutter developers range from people who have completed a course and built a sample app to engineers who have shipped and maintained several production apps. From the outside they all say 'Flutter developer', and the market prices them very differently because the outcomes differ. An experienced developer solves problems that a beginner does not know exist: offline behaviour, state management that does not collapse as the app grows, performance on low-end phones, app-store review rules.

Location matters too, though less than people assume, and the effect is changing as remote work becomes normal. A developer in a smaller city may charge less than one in a metro, while delivering equivalent work. The sensible assumption is that price correlates imperfectly with quality, so judge the work and not the rate.

Finally, there is the question of the type of work. A simple app built from standard components costs less per day than a performance-sensitive app with custom animations and complex data. The same developer may charge differently for each.

How to read the flagged rows in the normaliser

The tool above marks a quote pink if its effective day rate is far above the middle of your own quotes, and a muted colour if it is far below. These flags are not verdicts. They are prompts to ask why.

A very high row might reflect a team with a lot of seniority and process, or it might reflect padding. Ask what is in it. A very low row might be a talented person with low overhead, or it might reflect a scope that was misunderstood, a developer who will cut corners, or someone who has underpriced to win the work and will struggle to deliver. Ask what they have assumed.

The healthiest outcome is that you can explain each quote's difference to yourself in a sentence: 'this one includes design and testing', 'this one assumes I supply designs', 'this one is one person working longer'. When you can do that, you are choosing between actual options and not between numbers.

GST and other things added on top

In India, software development services are generally subject to GST. Quotes can be stated inclusive or exclusive of it, and the difference is significant. Ask which, and use the checkbox in the tool to take GST out of a total before comparing, so that you are comparing like with like.

Rates change, and the right treatment depends on your own circumstances, including whether you can claim credit for the tax. Check the current position with your accountant before relying on any figure.

Other items can sit outside a quote and still cost you: store account fees, cloud hosting, messaging and payment gateway charges, and maintenance after launch. They belong in your total cost of ownership, even though they will not appear on the developer's invoice.

How to negotiate without damaging the work

Squeezing the rate is the weakest way to get value. A developer who agrees to a lower rate may protect themselves by spending less time, or by cutting what you cannot see: testing, documentation, edge cases. The work gets thinner while the number looks better.

A better way is to negotiate scope. Ask what could be removed from version one to bring the price into range, and what could be added later. Ask whether a different milestone structure would reduce the upfront payment. Ask whether the developer would give a fixed price for a trimmed scope.

Be honest about your budget. A developer who knows the real constraint can design something that fits. One who does not will quote for the project they imagine and you will both waste time.

Why hourly billing is a poor fit for a first app

Hourly rates feel fair: you pay for the time spent. In practice they put the risk on the person least able to judge it. You cannot easily tell whether four hours on a task is reasonable, and neither can you tell whether the person was efficient or slow. The longer a task takes, the more you pay, which is the opposite of the incentive you want.

Hourly arrangements suit work that is truly open-ended, such as support, small fixes, and exploration. For a defined build with a clear scope, a fixed price against milestones lines the incentives up much better. The vendor is rewarded for efficiency and you are protected from drift.

If a developer insists on hourly billing for a defined scope, ask for a cap, or for a weekly estimate that you approve in advance. Either turns an open-ended cost into a bounded one without much loss of flexibility.

Questions to ask whatever the rate

1. What exactly is included in the rate, and what is not?
2. How many person-days does the quote assume, and how many people?
3. Is GST included?
4. What happens if the work takes longer?
5. What do fixes after launch cost, and for how long are they included?

If you remember only one thing: a rate is only meaningful with the scope next to it. A number without a scope is not information.