There is no reliable single price for a business web application without understanding its scope. A simple internal register used by a few people is a different project from a system that handles orders, settlements, integrations and work across several departments. Both may have a similar number of screens while containing a very different number of rules, exceptions and responsibilities for data.
At Domin Software, we prepare individual estimates. We first establish the problem the application should solve, who will use it, where its data comes from and what must work in the first stage. If there is not enough information, we propose a separate paid analysis instead of guessing a price from a short message.
The absence of a price list does not mean that the cost is arbitrary. The sections below explain what usually shapes the scope and what information helps us prepare a responsible estimate.
The process matters more than the number of screens
A login screen, a form and a record list may look simple. Much of the work is often hidden in rules that are not visible on the first mock-up.
An order form may need to check availability, apply customer-specific prices, request approval for a discount, reserve stock, send notifications and pass data to accounting. Each of these behaviours must be described, implemented and tested, including unusual situations.
Before estimating the work, we therefore ask about the real workflow:
- what starts the process and what its final result should be;
- who performs each activity and makes decisions;
- where data is created and who may change it;
- which exceptions, corrections and returns to an earlier step occur in practice;
- which other programs the application must work with;
- how the client and contractor will confirm that a stage has been completed correctly.
The clearer these answers are, the fewer assumptions the estimate needs.
What has the greatest effect on the cost?
Scope of the first stage
It matters whether the first release solves one clearly defined problem or immediately replaces several tools used throughout the company. A smaller stage should not be a disposable version. It should deliver a specific result that can be accepted and used.
When every idea enters one scope, the project grows by more than its list of features. Dependencies, work order and the point at which the system can be launched safely also become harder to establish.
Roles and permissions
One person working with their own records needs simpler rules than a system shared by an administrator, sales team, accounting, partners and external customers. We must decide who can see each type of information, who may change it, who approves a decision and how important changes are recorded.
Permissions require particular care where a mistake may affect an order, payment, settlement or customer data.
Data and migration
A new application rarely starts with an empty database. Information may be spread across spreadsheets, an old system, messages and files prepared by different people. Before importing it, we need to check formats, completeness, duplicates and the rules for joining records.
Moving a file is usually easier than deciding which values are current and what to do with missing information. The quality of source data can therefore change the migration scope considerably.
Integrations
An integration may fetch one value once a day or exchange orders, statuses and payments in both directions. Its scope depends on API documentation, authentication, limits, error handling and the availability of a test environment.
We also need to decide what the application should do when an external service is temporarily unavailable or returns incomplete data.
The detailed cost factors are explained in How much does a system and API integration cost?.
Business rules, exceptions and automation
Automation is useful when its conditions are known and it is clear when a person must still make the decision. A simple notification is a different task from calculating commissions, selecting an approval path or synchronising several statuses.
Exceptions are not an optional addition at the end. If they occur regularly, they belong in the process description and test scope from the start.
Security and traceability
An internal helper register has different requirements from a system containing customer data, settlements or information shared by several companies. Login rules, permissions, records of important operations, backups, updates and error handling all matter.
Security cannot be guaranteed by adding one feature. Its scope must reflect the data, the users and the consequences of a problem.
Testing and acceptance criteria
A function is not complete merely because it works in the simplest example. Valid and invalid data, unavailable integrations, different permissions and background tasks may all need to be checked.
An estimate becomes clearer when both sides know in advance what conditions must be met for a stage to be accepted. Without those criteria, the word “done” can mean different things to the client and the contractor.
Deployment and ongoing maintenance
The project may cover application development alone or also environment configuration, migration, launch, monitoring, backups, updates and further development. These are separate responsibilities and should be named in the offer.
External services may add their own costs, such as hosting, messaging, maps, payments or other APIs. These charges are not automatically included in the development fee.
We explain separately what affects web application maintenance cost after launch.
If you are considering a customer and sales management system, also see what makes up the cost of a custom CRM.
Three examples of different complexity levels
The following examples help compare scopes. They are not fixed packages, prices or delivery promises.
| Example | What the first stage might contain | What can increase the scope significantly |
|---|---|---|
| Internal register | forms, a record list, search, a basic export and one or two roles | import of old data, advanced permissions, change history and unusual validation rules |
| Operational process module | several workflow stages, statuses, notifications, different roles and basic reporting | many exceptions, automated decisions, settlements, advanced reports and several departments |
| Integrated system | data exchange with other services, migration, orders or settlements and multiple roles | poor data quality, missing API documentation, security requirements, external dependencies and complex tests |
Two companies may describe similar features and still receive different estimates. The difference becomes visible only after reviewing the process, exceptions, data and user responsibilities.
What is often missing from the first enquiry?
The first message usually focuses on visible features. Before estimating the work, it also helps to clarify:
- whether data must be imported and who can confirm its accuracy;
- whether external systems provide documentation and test access;
- who will manage accounts and permissions;
- which messages, files or documents should be created automatically;
- what happens when data is missing or the process takes an unusual route;
- who accepts each stage and on what basis;
- who is responsible for the server, domain, backups and external services;
- which licence and subscription charges may exist outside the contractor's work.
You do not need to know every answer. What matters is separating confirmed facts from assumptions and items that still need to be checked.
When can an estimate be prepared without a separate analysis?
A broader analysis may not be necessary when the problem is clearly limited, the process has few exceptions, the data is known and integrations have usable documentation. The scope, result and acceptance criteria are still required, but they can sometimes be established during a shorter offer preparation stage.
An initial qualification call with Domin Software may take up to 20 minutes and is free of charge. It helps us identify the problem, goal and materials needed for further assessment. It does not include application diagnosis, code review or a completed report.
When the project affects several departments, contains many unknowns, requires migration or connects several systems, we may begin with business analysis and an application MVP scope. This is a paid, self-contained stage. The client receives organised material that may also be used with another contractor. If Domin Software later implements the resulting project, the amount paid for the analysis is included in the total project cost.
How does Domin Software prepare an estimate?
We start with the problem and the expected outcome rather than selecting technology first. We then identify the process, users, data, integrations and constraints. A larger project is divided into stages, each with its own scope, result and acceptance method.
The estimate states what a stage includes and what remains outside it. If some information is not confirmed, we record the assumptions or recommend checking them first. We do not present an early guess as a certain price for the whole system.
The price, schedule and payment method are confirmed before work begins. Payment normally follows completion of the agreed stage. A deposit may be agreed for a larger scope.
Examples of where complexity comes from
The 44Islands booking system involved different roles, reservations, commissions and successive stages of development. Its complexity came from connecting sales with the work of administrators, sellers, drivers and tour leaders.
For HUB.ITM, an important part of the work was processing data from different programs and converting it into a format accepted by accounting systems. Input formats, transformation rules and validation shaped the scope.
HUB-2-API combined product imports, eBay listings and orders with an API used by B2B customers. A list of screens alone would not describe the work performed between those systems.
These examples are not a price list or a comparison of project values. They show why user roles, data and integrations must be understood before preparing an estimate.
What should you prepare for the first conversation?
A short, practical description is enough to begin:
- What problem should the application solve?
- How does the process work today?
- Who will use the solution?
- What data is needed and where is it currently stored?
- Which programs must the application work with?
- What must be included in the first useful stage?
- What can wait until later?
- How will you confirm that the first stage works correctly?
You do not need to prepare technical documentation. The free project brief builder can help organise this information before you contact us. Do not enter passwords, API keys or real customer and employee data.
Frequently asked questions
Can an application be estimated from a feature list alone?
Sometimes a very preliminary range can be discussed, but a feature list rarely shows rules, exceptions, data, integrations and acceptance criteria. The more unknowns it contains, the less reliable the number will be.
Are the first call and project analysis free?
The qualification call may be free and last up to 20 minutes. It does not include a diagnosis or report. Business analysis, code review and other stages that produce a defined deliverable are paid and estimated individually.
Can we start with a smaller version and extend it later?
Yes, provided the smaller stage solves a defined problem and has clear acceptance criteria. Elements required for safe operation should not be removed merely to reduce the initial cost.
Are integrations and data migration included in the estimate?
Yes, if they are included in the agreed scope. The systems, formats, API access, data quality and validation method need to be established first.
Must the application be built by Domin Software after the analysis?
No. The analysis material may be used with another contractor, subject to confidentiality and without public distribution.
Is the analysis fee included in later implementation?
Yes, when Domin Software implements the project resulting from the analysis. The amount already paid for the analysis is then included in the total project cost.
Why is the lowest initial estimate not always the lowest project cost?
A low figure may omit migration, exceptions, testing, deployment or maintenance. Compare not only prices but also the stated scope, assumptions, exclusions and acceptance method.
Prepare the information needed for an estimate
If you are still organising the idea, start with the project brief builder. It helps collect the problem, process, users, data and priorities without requiring a technical specification.
If the process has many exceptions, affects several departments or requires integrations and migration, see business analysis and application MVP scoping. We can define a safe first stage before estimating its implementation.