You asked three companies to quote for a mobile app or a web platform, and the figures are three times apart. That does not mean one of them is deceiving you. Most of the time all three have priced a different project. To compare proposals you need to look not at the price but at what the price covers.

How clear is the scope?

A proposal that says "mobile app development" in one line leaves the uncertainty with you. A good proposal lists screens or modules, user roles, integrations and supported platforms one by one. The more detailed the scope, the fewer "that wasn't included" arguments mid-project.

What is not included?

The items most often left out of proposals are:

  • Design: a ready-made template or a design made for you?
  • Admin panel: where will you manage content and users?
  • Testing: on which devices, with which scenarios?
  • Store processes: who handles App Store and Google Play submissions?
  • Server, licence and third-party service fees.
  • The bug-fix period after launch.

A quote that looks low may be leaving some of these out. Do not assume; ask.

Who will do the work?

Are the people across the table in the meeting the people who will work on the project? Who is on the team, how experienced are they, will the work be passed to another company? Having your questions answered directly by the person doing the work is one of the things that most affects how a project goes.

Who owns it?

Make sure three points are explicit in the contract: the source code is yours on delivery, store and server accounts are opened in your name, and third-party licences can be transferred to you. If these are not in writing, you will have no bargaining power when you want to change teams later.

How will the process run?

Is there a single delivery in six months, or will you see a working version every two weeks? With teams that demo regularly, problems surface early. Tying the payment plan to these interim deliveries is healthy for both sides.

What happens after launch?

Software is not finished the day it goes live. Operating systems update, security patches come out, users ask for new things. The proposal should include maintenance and support terms, response times and the monthly cost. When you calculate total cost, think of the first two years together.

A short method for comparing

Put the proposals in one table and ask of each row: is this item in this proposal, and in how much detail? By the end of the table you will see that most of the price gap is a scope gap. What remains is the team's experience and way of working, which you can judge from references and live work.

We prefer to run a short discovery before quoting, because a price for a project with unclear scope is no more than a guess for either side.