Two projects described as customer portals can require very different effort. One may display approved information to a few users. Another may support payments, multiple organisations, complex permissions, and several external systems. The label does not determine the cost; the behaviour and operational responsibilities do.
What are the main cost drivers?
Scope is the first driver: the number of journeys, roles, and business rules the product must support. A simple form becomes more involved when different users see different fields, approvals vary by region, and requests must be amended after submission. Each rule requires design, implementation, and verification.
Integration and data are often equally important. Connecting to a well-documented service with clean records differs from importing inconsistent spreadsheets or depending on an undocumented legacy system. Identify these uncertainties early. They can influence the schedule and cost more than the visible number of screens.
Why does discovery affect the estimate?
Discovery turns broad expectations into specific decisions. It identifies users, maps workflows, examines source data, and tests important technical assumptions. This does not need to become an open-ended exercise. A bounded discovery phase should produce a clearer scope and a list of unresolved questions with owners.
Ask what evidence supports the estimate. Has the supplier inspected the integration? Have representative users reviewed the main journey? Are permissions understood? An estimate made before these questions are answered should be presented as a range with assumptions, not as a precise commitment that hides uncertainty.
Separate build costs from operating costs
Build costs may include product discovery, interface design, application development, migration, testing, and deployment. Operating costs can include hosting, third-party services, monitoring, backups, support, and periodic updates. Some expenses vary with users or transaction volume, while others are recurring regardless of usage.
Ask for both categories in the proposal. Understand who pays external providers and who owns the associated accounts. A project can fit the initial budget and still become difficult to sustain if the running costs were not considered. The business should know what ordinary operation will require after the launch meeting ends.
How do different commercial models work?
A fixed-scope price can be useful when requirements and acceptance criteria are sufficiently clear. It gives a defined commitment, but changes need an agreed process. If the scope remains uncertain, a fixed price may contain a substantial allowance or exclude the work that later proves essential.
A time-based arrangement can accommodate discovery and changing priorities, but it needs visibility and spending controls. Use regular demonstrations, a prioritised backlog, and clear review points. Whichever model you choose, agree what constitutes completion and how new requirements affect the budget before development begins.
Example: comparing two portal proposals
Imagine one proposal includes a login, a request form, and a dashboard. Another includes those screens plus data migration, staff training, recovery testing, and support. The second may look more expensive even though the first leaves necessary work outside the quoted total.
Create a comparison sheet based on deliverables rather than totals alone. Ask each supplier to state assumptions about user roles, imported records, integrations, and post-launch help. This makes the comparison more honest and reduces the chance that a low initial figure becomes a series of unexpected additions.
Where can you reduce cost responsibly?
Reduce the first release to one complete, valuable journey. Reuse suitable existing services and avoid building administration features that the pilot does not need. Validate the interface before implementing every screen. Early feedback can prevent substantial rework when the team discovers that users interpret the process differently.
Do not remove essential controls merely to lower the quote. Permissions, reliable data handling, and understandable error states protect the core workflow. Cutting those areas may transfer cost into support, corrections, and future redevelopment. Scope reduction should remove optional value, not undermine the function you are paying to deliver.
What should a useful estimate contain?
- A description of the first release and the intended users.
- Included deliverables and a clear list of exclusions.
- Assumptions about integrations, data, and client responsibilities.
- Acceptance criteria and the approach to testing and review.
- Initial costs separated from recurring operating expenses.
- A process for changes, approval, support, and handover.
Also ask how uncertainty will be reduced. A short technical investigation might answer a costly integration question before the full project begins. Paying for a well-defined discovery result can be more economical than committing to a large build based on assumptions that nobody has tested.
Ask each supplier to list assumptions alongside the estimate. For example, an integration priced around a documented API may change if access is unavailable or historical records require cleaning. Discuss these dependencies before comparing headline prices, and assign someone to resolve each open question.
Frequently asked questions
Can you quote accurately from a feature list?
A feature list supports an initial conversation, but it rarely captures permissions, exceptions, data quality, and operational needs. A supplier can provide an indicative range, then refine it as assumptions are validated. Accuracy improves when the expected behaviour is described in concrete examples.
Does using AI guarantee a lower project price?
No. AI may reduce effort on suitable drafting or implementation tasks, but review, integration, testing, and support still matter. Ask how the delivery method changes the scope or effort of your specific project. A tool choice alone does not establish the total cost.
How much contingency should we allow?
There is no useful universal percentage for every project. The allowance should reflect unresolved dependencies and the consequences of changes. Ask the supplier to identify the main uncertainties and explain how they will be investigated. A transparent assumption register is more useful than an unexplained buffer.
Prepare for a better estimate
Bring a description of the main workflow, sample information, existing systems, and the deadline's business reason. Include the people who know the daily exceptions. A productive estimating discussion should clarify trade-offs and produce a first release that fits both the business objective and a realistic ownership budget.
