Price is not a screen count
Application budgets are driven by business rules, roles, data flows, integrations, and uncertainty. Two products with ten screens can differ dramatically: one displays content while the other governs prices, permissions, and payments.
Ask what result the first release must create and what it must do reliably. For a clearly scoped web application or one mobile platform, DAVOND's minimum budget is €9,900 excl. VAT, with a typical 10–16 week delivery window.
- user roles and permissions
- complexity of the primary workflow
- quality and availability of input data
- external APIs, payments, and notifications
- security, migration, and operational requirements
A useful base scope
A first release should not be a cheap demo without operating value. It should cover one primary flow end to end, the required administration, authentication, basic roles, QA, deployment, documentation, and post-launch stabilization.
A mobile requirement does not automatically mean web, iOS, and Android. Select one platform or a cross-platform approach after understanding the trade-offs.
How to read a proposal
Compare package boundaries, not only the final number. A sound proposal lists assumptions, inclusions, exclusions, acceptance, and change pricing. Otherwise a low headline amount can become a trail of add-ons.
Ask about source-code rights, deployment, backups, monitoring, documentation, and the post-launch period. Those details separate an operational product from a folder of source files.
- Is the price fixed for a defined scope?
- What inputs must the client provide?
- How are changes approved?
- What exactly means done?
- Who handles a post-launch incident?
When discovery should come first
If the primary workflow, users, or data sources are unclear, do not start development with a blind estimate. A focused discovery or R&D sprint reduces uncertainty and produces decision-ready evidence.
An introductory consultation is orientation, not a free full specification. We clarify the problem, solution type, key risks, and next step—and say openly when custom development is not the sensible investment.
Protect the budget with stages
For a larger product, approving investment by stage is healthier than pretending one annual number is precise. Each stage should have an outcome, a budget, and a decision to continue, change direction, or stop.
Contingency should cover real uncertainty rather than an undefined scope. Test critical integrations and migrations before building the rest of the product on top of them.
- separate the essential core from later phases
- prototype risky integrations early
- track delivery and operating costs
- review value after every stage