Online “calculators” and averages are tempting, but two apps with the same number of screens can differ by an order of magnitude in effort. The better way to think about cost is to list what the system has to know and do.
What actually drives it
- Users and roles. One kind of user is simple. Customers, staff, managers and administrators who see and change different things are not.
- Data and rules. The more entities and the more rules between them, the more to design, build and test.
- Integrations. Each external system brings its own documentation, limits and failure modes.
- Payments, notifications, files. Common features that each carry hidden detail.
- Reporting. Dashboards and exports are often wanted late and take real time.
- Quality bar. Automated tests, security review, accessibility and monitoring cost effort now and save larger costs later.
How to keep the budget honest
- Write the main user journeys step by step. Number every function you find.
- Mark each as essential for launch, useful later, or nice to have.
- Build the essentials first and put real users on them.
- Budget separately for running it: hosting, backups, updates, support, and further development.
About fixed prices
A fixed price is reasonable when the scope is written down and unlikely to move. When the requirements will be learned along the way, working in small, reviewed stages with a clear budget cap tends to produce a better result than a fixed price that gets renegotiated at each surprise.