Start with the scope
The cost of a custom web application depends on the processes it must support, its data, user roles and integrations. Screen count alone does not describe the work. Two applications with ten screens may differ substantially when one displays information and the other coordinates approvals and synchronisation.
This guide explains how to prepare an estimate without inventing a market average or universal rate. A useful proposal defines deliverables, exclusions, who provides the data and how acceptance works. The final price follows clarification of those elements.
What goes into an estimate
Start with people and their actions: who creates a record, who can see it, who approves it and what happens after an amendment. Permissions, history and exception handling may require more work than the initial interface. Describe both the normal path and at least one realistic failure for each workflow.
Separate discovery and design from implementation, testing, migration and operational preparation. An integration also depends on the vendor API, licensing, test access and data quality. If documentation is missing, assessing that dependency belongs in the scope rather than inside an unsupported delivery promise.
Three examples of scope
Illustrative example — document portal: a first version might support uploading, reviewing and downloading files for defined roles. Electronic signatures, invoicing and historical imports are separate decisions. Accepted formats, size limits and access after a user leaves all need definition.
Illustrative example — CRM: enquiry → qualification → proposal is a different scope from a platform also covering projects, support and accounting. Illustrative example — configurator: a few options with an indicative estimate differ from multiple commercial rules, negotiated pricing and inventory reservations. These examples explain scope; they are not claims about delivered projects or client outcomes.
The first release and acceptance
Choose one complete workflow that can be used and checked. A long list of partial modules is difficult to accept and estimate. Define inputs, expected results, the responsible role and an observable acceptance criterion. Use fictional examples or authorised test data.
Agree how new requirements are handled. When another integration or business rule appears, assess its effect on scope and milestones before implementation. This makes proposals easier to compare: the same module name does not necessarily mean the same deliverables.
The budget continues after launch
Hosting, external services, maintenance, monitoring and backup verification are operating costs. Decide who updates the application and who responds to an incident before launch. An archive existing is not the same as a verified restoration.
For the first discussion, prepare a workflow example, roles, existing applications, known approximate volumes and timing constraints. Mark missing information as unknown. An honest brief supports better staging than a seemingly precise budget built on assumptions.
Common questions
Can an idea alone produce a fixed price?
An initial scope can be discussed, but a responsible proposal needs workflows and dependencies clarified. There is no assumed universal application price.
Does a first release mean less testing?
No. Its scope is smaller, while included workflows still need testing and acceptance.
What should I send for an estimate?
A workflow example, roles, existing applications and the intended outcome. Remove personal data from examples.
Sources and further reading
An AURENIQ editorial guide. Examples are illustrative, not client results. Vendor documentation is checked for the specific implementation.
Services for this topic
What is the next step for your project?
Describe the problem, the people involved and your existing applications. We can clarify a useful first version and its dependencies before preparing a proposal.
Discuss your project ↗