App Development: How to Compare Cost and Quotes

Agree the scope before comparing figures

The cost of building an app becomes comparable only when quotes cover the same work, the same checks and a defined period of use. Separate the initial investment from licences, infrastructure, support and later changes. Ask for an explanation of every unclear line; a missing price does not mean the cost is zero.

One quote may include migrating old data and training; another may cover development only. One may charge a monthly fee per user; another may include a limited service package. The final figures then answer different questions.

This guide is about preparing a comparison, not about presenting a universal price list. If you are still weighing buying against building, start with the software buying guide.

Give every supplier the same description of workflows and user roles. List the data to be transferred, external systems and devices. Mark required features and open questions clearly.

A feature name is not enough. “Approving a request” can mean a single button or several levels, substitutes for absent approvers, a return for more information and a history of decisions. Ask for a description that shows what was estimated.

Use a table to support the comparison, marking each supplier as included, excluded or unclear. Resolve the unclear items first.

A smaller scope can be a reasonable choice. What matters is knowing which actions then stay outside the app and who will handle them.

Separate the initial cost from the running cost

Under the initial part, record the agreed analysis, development, integrations, data migration and go-live. For services that depend on a prior check, state the assumptions or add a separate line for that work.

For ongoing use, note what is charged monthly, yearly or by consumption. Give every line a unit: user, organisation, message, data volume or an agreed package. Check what happens when usage exceeds the included level.

Microsoft's guidance on estimating the cost of an Azure environment ties the estimate to architecture and usage assumptions, alongside operational needs such as training. The principle is useful when comparing app quotes too: the assumptions should be visible.

Do not assume that maintenance always equals a set percentage of the build cost. Ask which work, limits and responsibilities the actual quote covers. Compare the billing frequency as well, and the conditions for a price change.

A hypothetical example: the total over 36 months

The figures below are entirely made up and serve only to explain the arithmetic. They are not market prices, a Novero quote or a forecast for your project.

Suppose two quotes cover the same described scope of an internal application, the same users and the same assumed usage. Support and hosting are comparable in this example. All amounts are in euros, excluding VAT, and the monthly fee applies throughout all 36 months.

The arithmetic is 8,400 + (36 × 180) = 14,880 EUR for A and 2,400 + (36 × 360) = 15,360 EUR for B. The difference is 480 EUR under the stated assumptions. A lower starting figure in this example does not mean a lower total over the chosen period.

If both quotes also exclude a hypothetical 1,200 EUR for migration, the comparable totals become 16,080 EUR and 16,560 EUR. If only one quote excludes migration, apply the same addition to that quote alone. Check what a line contains before you calculate.

This simple nominal model excludes price changes, growth in usage, the cost of financing, inflation, the buyer's tax position, exit costs and further development. Some items may not exist in a real project; others still need estimating. Choose a period relevant to your decision and apply it consistently to both options.

Check what maintenance actually covers

A package name often hides several different kinds of work. Ask for a clear split between fixing a defect, a security update, an adjustment for a changed external service and a new feature.

Also clarify:

• how a problem is reported and in which working hours it is monitored;
• what incident severity levels mean;
• whether a stated deadline refers to a response, the start of work or an expected resolution;
• whether an amount of work is included and how additional work is billed;
• who monitors infrastructure, backups and external services.

Do not compare only the number of support hours if the coverage and responsibilities differ. Likewise, an agreed response to a report is not the same as a promise that every fault will be fixed within that time.

Tie the price to how delivery is accepted

A comparable quote should show how you will verify that the agreed work functions. Replace the requirement “the app is finished” with scenarios that have an input, an action and an expected result.

Microsoft's pre-go-live checklist for Dynamics 365 covers user acceptance, integrations, performance and support readiness. Choose the checks you need and the people responsible, without copying that whole model.

If the project includes a mobile app, the mobile development guide offers further questions on platforms and publishing. In the specific quote, still confirm the included devices, publishing accounts and post-delivery obligations.

Record the terms for change and exit

Agree in advance how a new request is estimated and who approves it. If the original scope changes, the comparison table has to change too. Do not compare one supplier's old price with another's expanded scope.

Clarify the rights to the code, design, documentation and the components used. Check who controls the accounts and what another team would need to take over maintenance. Custom development alone does not settle every licence and contract term.

For exit, consider the export format, related files, help with the transfer and any fees. These are questions for a specific model of cooperation, not a claim that every app must have the same cost structure.

What to prepare for a real cost estimate

For a conversation about custom business software development, prepare the main process, the roles, the systems, the available data and the reason behind your deadline. Add the expected number of users and actions, and what can wait for a later version.

When the quotes arrive, ask for unclear lines to be clarified before the final comparison. A useful closing review shows the same scope, assumptions, period, initial costs and terms of use.

Send Novero a description like this. It opens a conversation about a concrete estimate and what it includes.

Sources

• Microsoft: Estimate the total cost of ownership of an Azure environment — the estimate is tied to architecture and usage assumptions, alongside operational needs.
• Microsoft: Prepare for go-live checklist (Dynamics 365) — user acceptance, integrations, performance and support readiness.