How much does app development cost? Why quotes vary so widely and how to compare them

Take a hypothetical case: a company wants a bespoke app, sends the brief to three suppliers and gets back three quotes, the most expensive of which is several times the cheapest. The first suspicion is predictable: someone is overcharging.

The difference, however, may lie in what the supplier has priced in, what it has omitted and what risk it has left with you.

Whether a custom system pays off is something we look at in our article on a system versus a new hire. Here we pick up a step further on, with the quotes already on the table and one question to answer: how much does app development cost when every supplier pictures the app differently?

A several-fold price gap does not necessarily mean overcharging

In a 2009 study, Bente Anda, Dag Sjøberg and Audris Mockus described a tender in which Simula Research Laboratory was looking for a supplier for a web-based system. Of the 81 companies approached in Norway, 35 submitted a fixed-price bid, all for the same 11-page specification. Prices excluding VAT ranged from €2,630 to €69,940, a roughly 26.6-fold difference. What is instructive is the ratio, not the amounts, which are by now historical.

The companies themselves considered the requirements well specified. Even so, the bids also differed in how much analysis and design they included, ranging from none at all to screens, architecture and data models. The authors found no link between price and the planned approach, and in their view the bids revealed only to a limited extent how a company works and what quality it aims to deliver. The price alone, then, will not tell you what you get for it.

In a preliminary phase of the same tender, 17 of these companies gave a non-binding estimate based solely on a one-page description of needs. According to Magne Jørgensen and Gunnar J. Carelius, the highest was roughly ten times the lowest, owing, among other things, to differences in the proposed solutions and in productivity. The authors point out that when a specification is vague, the bid price does not merely reflect the project but also defines it.

What goes into the price

If the brief is silent, the supplier will make these decisions for you:

• Feature scope. What the app will and will not do. The sentence ‘the user can generate a report’ can mean anything from a spreadsheet export to an analytics module.
• Integrations. Connections to your accounting software, for example. How demanding they are depends on interfaces the supplier may not be familiar with.
• Design and UX. UX, or user experience, affects whether people adopt the app, as we explain in our article on why the most expensive system is the unused one. A ready-made template is cheaper than a design tested with users.
• Data model. The structure of the data and the relationships within it. Everything else rests on it, which is why its flaws are hard to fix.
• Security and permissions. A single role for everyone is cheap, whereas access based on job position has to be both designed and tested.
• Testing. Automated tests that run after every change confirm that existing features still work. Without them, your own people do the testing.
• Project management. Coordination and change control. Check whether it is included in the price or whether someone on your side will have to do it.

Differences also lurk in non-functional requirements, which describe not what a system does but how well it does it: speed, reliability or maintainability, meaning how easily it can be changed. In the Norwegian study, they were described in less detail than the functional requirements, and the authors recommend specifying them, maintainability in particular, at the brief stage. The quality model in the ISO/IEC 25010:2023 standard, which clients can also use when drawing up a specification, can help here.

What a quote may leave out

Check these items with every supplier. If the brief did not mention them, one supplier may have included them and another may not.

• Admin interface. Managing users, reference data and content. Without it, every minor change becomes billable developer work.
• Data migration. Moving and cleaning data from the old system or from spreadsheets.
• Multilingual support. If the code does not allow for it from the outset, adding it later can affect a large part of the app.
• Accessibility. Usability for disabled people as well. Addressing it after the fact means reworking finished screens.
• Post-launch support. Fixes, security updates and help for users. If it is missing, the first problem after go-live becomes a new order.

We break down the costs over years of use in our article Seven SaaS tools or one system? When reading a quote, you only need to take one point from it: code without tests and documentation is cheaper to deliver but more expensive to change, because with every modification a developer first has to work out what the change will break.

Who bears the risk: fixed price, time and materials, hybrid

Fixed price means the supplier bears the risk of cost overruns and therefore builds it into the price: the vaguer the brief, the larger the contingency or the narrower the interpretation of scope. The Federal Acquisition Regulation, which governs US federal procurement, states that a firm-fixed-price contract places maximum risk on the contractor and that the contract type should be negotiated together with the price. It is not our legal system, but in our view the logic is transferable.

Time and materials means you pay for the hours worked at agreed rates and you bear the risk of uncertainty. The same regulation permits it only when the extent or duration of the work cannot be estimated accurately in advance. Because this model gives the contractor no incentive to control costs, the regulation requires oversight by the buyer. It also requires a ceiling price, which the contractor exceeds at its own risk.

A hybrid with a fixed first milestone puts a fixed price on the first phase with a clear deliverable, such as analysis or a prototype, while the rest is decided only once the scope has been documented. The supplier carries the risk of a small phase, and you make decisions about most of the budget with better information. The first phase does cost both money and time, however, and its output must be usable by another supplier as well; otherwise you are buying dependency one phase earlier.

You pay for an imprecise brief during development

A change request is a formal request to alter the agreed scope, with its own price and its own impact on the deadline. With an imprecise brief, the exception becomes the rule, because the missing parts only come to light during development.

Jørgensen and Carelius report that changes to requirements which cannot be invoiced to the client are a common cause of supplier cost overruns. In our view, a supplier that won on a low price therefore has a strong incentive to bill every deviation as a change. If the contract does not set out the rate, the estimation method and the approval process for changes in advance, you end up negotiating their price at a point when you can no longer easily replace the supplier.

Invoices are not the only way you pay for an imprecise brief, however. The Cost of Friction framework we use on this blog calculates the cost of friction as time × frequency × number of people × cost. A worked example with hypothetical inputs: 30 unclear points in the brief, each taking up two hours of meetings for three of your people, amount to 2 × 30 × 3 = 180 hours of internal work. Nobody will invoice you for it, yet you pay for it all the same. Plug in your own figures and hourly cost.

Rights to the code and the ability to switch suppliers

Vendor lock-in is a situation in which you cannot easily replace a supplier because only that supplier understands the system. In 2016, the European Commission stated that 42% of the organisations it monitored had admitted to experiencing ICT lock-in.

Under section 91(4) of the Slovak Copyright Act (Act No. 185/2015 Coll.), in the version in force from 1 September 2026, a computer program created wholly or partly on commission is subject to the provisions on employee works, and the client is deemed to be the employer. Unless agreed otherwise, it is therefore the client who exercises the economic rights, in particular the right to use the work, and who may assign the exercise of those rights to a third party; the author is also deemed to have consented to alterations of the work (section 90, subsections 4 to 6). That is Slovak law; other countries may regulate this differently, so whatever the jurisdiction, the contract should state explicitly who owns the code.

The Act defines a commissioned work as a work created under a contract for work, and what the parties have agreed is also decisive. Moreover, the Act deals with rights, not handover: without the source code in your repository, access credentials and documentation, the right to alter the work is of little use.

The contract should also cover the ready-made elements the supplier brings along, such as its own platform or paid-for components, because these were not commissioned by you. This is not legal advice: have the contract reviewed by a lawyer.

How to compare quotes

Send every supplier the same questions and record the answers side by side:

1. What is in scope and what do you explicitly exclude from it?
2. What assumptions have you made about integrations, data and roles?
3. How do you handle performance, security and maintainability, and what do you test?
4. How do you price and approve changes to scope?
5. What does post-launch support include, and how much does the first year of operation cost?
6. What rights to the code will we get, where will it be stored and how will a handover to another supplier work?

The authors of the Norwegian study recommend that bids state working practices and quality ambitions explicitly, not just implicitly through the fixed price. We regard the following as warning signs:

• A fixed price with no questions. A vague brief priced at a fixed sum without any clarifying questions may rest on a narrow reading of the scope or on a contingency you do not know about.
• No testing. It will then be your users who find the bugs.
• Unclear rights and access. It is not clear where the code will be stored, or access is tied to the duration of the working relationship.

When the cheaper quote is the right choice

Four companies from the Norwegian study went on to develop the system independently. The cheapest of them, at €8,750, overran the agreed schedule by 93%, with poor reliability and maintainability. The most expensive, at €56,000, overran by 5%, with good usability and maintainability. In terms of price it was 6.4 times more expensive, but once the client’s own work was factored in, only 3.4 times. The results did not mirror the price ranking, and according to the authors the cheaper system could have been the best choice for a client who tolerates delays, has sufficient expertise and has lower requirements for certain aspects of quality.

This could be, for example, an internal tool with a short lifespan or the validation of an idea.

In Magne Jørgensen’s data on 785,325 mostly very small projects on a global outsourcing marketplace, the factor that most reduced the risk of failure was a client’s previous collaboration with the supplier, which cut the risk to 17% of the level seen in projects without it. Clients who chose a bid priced at or above the average had, all else being equal, a risk 85% as high as that of clients who put more emphasis on a low price. According to the author, this can be generalised to larger projects only with caution. In his view, the best way to vet a supplier is a realistic trial, such as a real project, and a small paid first phase can serve as one.

A discovery phase turns an estimate into a plan

Steve McConnell describes the Cone of Uncertainty, a model of how estimation accuracy improves over the course of a project. At the initial concept stage, even estimates by skilled estimators can be out by a factor of four in either direction, which amounts to a 16-fold range, and in his view greater accuracy is not possible. The cone is not narrowed by another week of work on the estimate, only by decisions about what the product will and will not do, about the requirements and about the user interface.

These decisions come from analysis or a prototype. Suppliers are then at least pricing the same scope, although, as the Norwegian study showed, that does not guarantee similar prices.

The companies that first estimated from the one-page description in that tender later bid higher prices for the detailed specification, on average, than the others did. Jørgensen and Carelius therefore recommend not asking for indicative prices based on incomplete information if the final bids can be based on more complete information.

Paid analysis is not mandatory, though. For a small, clearly scoped app, refining the brief in-house may be enough. Analysis may also reveal that you do not need development at all, because simplifying the process or an off-the-shelf tool will solve the problem. That is why there is no honest answer to how much app development costs until it is clear what problem the app is meant to solve.

Key takeaways

• A several-fold gap between quotes does not necessarily mean overcharging. It may reflect a different scope, a different solution or a contingency for risk.
• Send every supplier the same questions and compare scope, exclusions and assumptions, not just the final figures.
• If the brief can be made more precise, do not ask for indicative prices based on a vague description. Where the scope is unclear, start with a fixed-price discovery phase whose output another supplier could also use.
• Before signing, make sure the contract covers rights to the code, access, documentation and ready-made components, and have it reviewed by a lawyer.
• The cheaper quote can be the right choice if you can live with delays, have lower quality requirements and have the expertise to keep a close eye on delivery.