Screens are not a reliable unit of complexity
Two products with twenty screens can require very different effort. Roles, permissions, business rules, data quality, reporting and integrations usually determine more work than the visible interface.
The phases behind a serious estimate
Discovery, experience design, architecture, engineering, testing, deployment, documentation and support should be visible in the proposal. Separating them makes assumptions, responsibilities and acceptance criteria easier to compare.
Integrations and data change the budget
Connecting an ERP, payment provider or legacy database introduces authentication, mapping, error handling and operational dependencies. Data migration also needs profiling, cleanup, validation and a rollback plan.
Security and reliability are product requirements
Access control, audit trails, backups, monitoring and recovery should be discussed before launch. Adding them after an incident is usually more expensive than designing them with the first release.
Reduce risk with a focused first release
A definition phase and a narrow first workflow help the team test the highest value assumption before investing in secondary modules. The result is a clearer roadmap rather than an artificially low initial quote.
Frequently asked questions
Can you estimate from an idea alone?+
A broad range may be possible, but a dependable proposal requires workflows, users, integrations, constraints and acceptance criteria.
Should the lowest proposal win?+
Not necessarily. Compare what is included, what remains assumed, ownership, testing, documentation and the cost of operating the product after launch.
Who should own the source code?+
Ownership and access should be explicit in the agreement, together with infrastructure, credentials, third party licenses and handover conditions.