Software development
What determines the cost of a business application
The cost of a business application is driven by processes, data, integrations and operational requirements rather than screen count. This article is intended for companies and public-sector organisations planning a new system or replacing an existing one.
Published 23 August 2026
Cost starts with scope, not screen count
The user interface is only one layer of a business application. Behind it are the database, business rules, access controls, API integrations, infrastructure and operational monitoring.
A simple user flow can require substantial logic underneath: the system has to validate data from several sources, resolve the user's permissions, generate a document, push data into another system and store an audit trail.
A useful estimate therefore starts with processes, user roles, data structures, integrations, migration, administration, infrastructure and the expected QA, DevOps and SLA model.
If these elements are undefined, a quote is an estimate built on assumptions. The more open questions remain, the higher the risk of scope changes during delivery.
- business processes
- user roles
- data model
- API integrations
- data migration
- QA and acceptance
- DevOps, infrastructure and SLA
Business logic is a major cost driver
UX/UI matters, but enterprise software must first execute business rules correctly. Status transitions, approvals, permissions, documents and data processing often create more complexity than the visible interface.
Each additional state, exception or dependency increases the amount of analysis, implementation and QA required.
Estimating means answering concrete questions: who can create a record, who can change it, when it locks, who approves it, what happens on rejection, which fields are mandatory, what is pushed to the ERP or CRM and what must be retained for traceability.
If those rules cannot be described up front, they will be defined during development, which directly increases analysis, implementation and QA effort.
Integrations can change the scope significantly
An ERP, CRM or other system integration cannot be scoped simply by confirming that an API exists. Documentation, authentication, available data, technical limits and test environments all need to be reviewed.
The project must also define responsibilities and system behaviour when an external service is unavailable or returns invalid data.
An integration with documented APIs and a test environment is a fundamentally different project from one where the data flow still has to be investigated.
Data migration requires its own analysis
Migration may include users, documents, historical records, statuses and other business data. Source data must be assessed, mapped to the new structure and validated before production migration.
The acceptance process for migrated data should also be defined before implementation.
Records whose meaning drifted over the years, or that were never entered consistently, are the usual source of trouble.
- who provides the data export
- in what format the data is available
- how many separate sources exist
- whether documents and attachments are migrated too
- who signs off the migrated data
- whether a trial run precedes the final migration
A web application and a mobile application are not one project
A system that only needs a web interface has a different scope from one that also ships a mobile application, which can require different user flows, interface work and device testing.
If part of the functionality must work offline or use device features, the technical scope grows further. The specification should state clearly whether the project covers web, mobile or both.
For the Zdravo Jem project with the Municipality of Sevnica we built the software for an interactive kiosk. That is not a website on a larger screen: it has to suit on-site use, touch interaction and the constraints of the hardware.
AI requires a defined use case
AI should be specified as an operational capability rather than a generic project label. Examples include document processing, RAG-based knowledge access, AI agents and workflow automation.
When an AI agent acts on external systems, API integrations, access controls and explicit action policies become part of the architecture.
Kwizmo is one example of Epix's enterprise AI work.
QA, DevOps and SLA are part of the system
A feature being implemented does not mean a system is ready for acceptance. QA, acceptance criteria, integration tests, permission checks and end-to-end business scenarios form part of delivery.
After launch, infrastructure, monitoring, deployment procedures and support responsibilities must also be defined. Guaranteed response levels should be documented through an SLA.
Changes during a project are normal, but they must be controlled
On any information-system project the need for change appears sooner or later. The problem starts when nobody can tell whether a change belongs to the original scope or is an addition to it.
A good specification is therefore not only a basis for pricing but also for managing delivery. Every significant change should be assessed against development, the data model, integrations, QA and infrastructure.
If a project starts with an unclear scope, those decisions move into the development phase. The consequence is not only cost, but considerably more coordination between the client, the developers and other contractors.
What is needed for a reliable estimate
An initial estimate requires a description of the current and target process, user roles, core functionality, integrations, migration requirements and basic infrastructure and security constraints.
For public procurement, a sufficiently precise technical scope also improves comparability between bids.
Where a system already exists, access to its technical documentation, architecture, database and existing APIs is equally useful.
- the current and the target process
- user roles and permissions
- the core functionality
- systems to integrate with
- data to migrate
- security and infrastructure requirements
So what does a business application cost
Without a defined scope, quoting a concrete price would be speculation. The total cost is built from analysis, UX/UI, software development, database work, business logic, integrations, migration, AI capabilities, QA, DevOps, infrastructure and ongoing support.
Epix develops software, AI systems and process automation for companies and the public sector. Relevant projects include Kwizmo, Smart Venue Platform, BeatLogic.ai and the Zdravo Jem interactive kiosk for the Municipality of Sevnica.
Frequently asked questions
Can an application be priced from a feature list alone?
Only approximately. A useful feature list must also describe business rules, user roles, integrations, data and technical constraints because apparently similar features can require very different implementations.
What usually has the greatest impact on application complexity?
The main factors are business logic, integrations, data structures, migration, access controls, AI capabilities and operational requirements for infrastructure, QA and SLA.
Is a mobile application automatically included with a web system?
Not necessarily. Mobile delivery should be explicitly scoped because it can require additional user flows, interface work and QA.
Why should data migration be estimated separately?
Migration complexity depends on source quality, data structure, number of sources, documents, mapping rules and the validation process after transfer.
Related
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.