When planning an app, it helps to separate two questions: what should the finished product be able to do, and what do you need to build first. These don't have to be the same scope.
In this article we'll look at what drives the price of a first version, which items to check in a quote, and how to compare budgets without mixing up a simple prototype with a complete system.
What are you actually comparing
When you get three quotes that differ several times over in price, it usually doesn't mean one vendor is expensive and another is a bargain. It means each of them priced a different assignment.
A clickable prototype
A clickable mock-up of screens. It looks like an app, but it doesn't store or calculate anything. Its purpose is to let you see the flow and show it to the people who will use it.
A first working version
An app where the main scenario actually works: data is really saved, users log in, the result can be used in practice. It deliberately doesn't include everything.
A larger system
More roles, more scenarios, connections to other systems, change history, dashboards and more demanding operational requirements.
A first working version isn't automatically a solution ready for any kind of operation. What it needs to handle depends on how it's used: a tool for five people in one company has different requirements than an app that hundreds of customers use every day.
So before comparing quotes, first clarify which of these three things each vendor is actually offering you.
What makes up the price
The price isn't a single number from a price list. It's made up of the following items, and for each one you can check in the quote how the vendor calculated it.
The number and complexity of user scenarios
Not the number of screens, but the number of things a user must be able to complete from start to finish. Question for the quote: which scenarios are included and which aren't?
User roles and permissions
One type of user is significantly simpler than four roles with different access to data. Question: how many roles does the quote assume, and what can each of them see and change?
Integrations
Connecting to accounting, an e-shop, a warehouse system, or a calendar. The price depends on whether that system has a usable interface and whether you have access to it. Question: is the integration included in the price, or is it a separate stage?
For POS, payments and fiscal systems, designing the layer between systems can be a separate challenge. We explain it in How to connect POS, payments and fiscal systems without replacing everything.
Data migration and data quality
Transferring data from spreadsheets or an older system is separate work. If the data is inconsistent, cleaning it up often takes longer than the transfer itself. Question: who prepares and checks the data?
Design
The difference between using established components and graphics designed from scratch. Question: is this custom visual design, or a clean, clear interface built from standard elements?
Testing
Going through the agreed scenarios, including error states. Question: what exactly is being tested, and who confirms that it works?
Operational requirements
Number of users, sensitivity of the data, need for backups and availability. Question: what level of usage does the quote assume?
Handover and support
What you receive at the end, and what happens afterwards. Question: what exactly is part of the handover, and what scope of support is agreed?
If two quotes answer these questions differently, they aren't comparable — regardless of which one has the lower number.
Where you can actually save
A smaller first scope
The biggest saving isn't in the hourly rate, but in not paying for features that end up not being used. A cheaper first version is a good deal precisely because it deliberately doesn't include everything — not because it's done superficially.
A clear specification
An unclear specification means rework, and rework is the most expensive form of development. It helps to agree the scope in writing before work begins.
Suitable existing components
Login, notifications, payments or exporting to spreadsheets don't need to be invented from scratch. Using proven components saves time and later maintenance effort.
Using AI for specific tasks
AI tools help with repetitive work — interface basics, standard code, draft tests. The time saved shows up in the price. We cover this in more detail in the article App development with AI: when it makes sense and what to watch out for.
You can't save on understanding the problem or on checking the result. That's exactly the part that determines whether the solution will actually be usable.
What to check even when developing with AI
Generating code faster isn't the same as a verified result. Regardless of the tools used, it's worth going through:
whether the agreed scenarios really work from start to finish;
who can see and change which data;
what happens on error — wrong input, dropped connection, double submission;
whether the solution can handle the expected usage, and whether data backups exist.
This is general guidance for any project, not a list of deliverables automatically included in every delivery. Which of these is included in our work depends on the agreed scope — and it's one of the things we clarify before starting.
What you pay after launch
An app needs somewhere to run, so operating costs arise after handover:
hosting and database;
domains and certificates;
paid interfaces and external services, for example email, maps, payment or AI services;
maintenance: updates, bug fixes, reacting to changes in connected systems;
further development based on what actual usage shows.
Their size depends on the providers and on the volume of usage, so it only makes sense to calculate specific figures for a specific assignment. A small internal tool usually involves an entirely different order of magnitude than a public-facing app.
Example scenario: an internal order-management tool
The following is an illustrative example to explain scope, not a delivered client project.
A company currently manages orders in a spreadsheet and over the phone. Nobody knows exactly who is responsible for what and by when.
First version
creating an order with basic details;
assigning a person responsible;
order status and deadline;
a simple overview of who has what open.
At this point the company already stops hunting for information in the spreadsheet and on the phone. That's a measurable change.
Later expansion
a client portal where the customer can see the status of their order;
invoicing and a connection to accounting;
integrations with other systems;
advanced reports and analytics.
The price difference between these two scopes is a multiple. The difference in when the company stops lacking an overview is zero — the first version already delivers that.
Summary
First clarify what you're comparing: a prototype, a first working version, or a system.
The price is made up of scenarios, roles, integrations, data, design, testing, operations and handover. For each item you can find out how the vendor calculated it.
You save with a smaller first scope and a clear specification, not by skipping the check of the result.
Add operating costs on top of the development price — they keep running after handover.
If you're weighing what belongs in a first version, the article How to validate an app idea before investing in full development can help too.
