Price the working outcome
A portal with five screens can require more work than a website with fifty pages. Screens do not show permission rules, data quality, external integrations, background processing or recovery requirements. Describe the business outcome and the complete workflow first. Identify who creates information, who approves it, what changes later and what happens when a step fails.
The estimate should explain assumptions and exclusions, not hide them behind a single number or an arbitrary count of pages.
Identify the main cost drivers
| Driver | Questions to resolve |
|---|---|
| Workflow | How many roles, decisions and exceptions exist? |
| Integration | Are APIs documented, accessible and testable? |
| Data | Who cleans, maps and validates existing records? |
| Assurance | What security, accessibility and acceptance checks are required? |
| Operation | Who hosts, supports and monitors the application? |
These dependencies should be visible in the scope even if another supplier owns them.
Use discovery to reduce material uncertainty
Discovery can include process mapping, sample-data inspection, an integration test and a prototype of a difficult interaction. Its purpose is to answer questions that affect scope or feasibility, not produce documentation for its own sake. A supplier should explain which decisions the work will resolve and what you receive.
If a critical API cannot be accessed or the existing data cannot be inspected, an apparently precise fixed quote may simply transfer uncertainty into exclusions and later changes.
Separate effort from elapsed time
Development effort and calendar duration are different. Access approvals, feedback, content, third-party support and user testing can extend delivery without adding the same amount of programming. Agree who supplies each input and when decisions are needed. Include time for correction and retesting, rather than treating the first working demonstration as completion.
An illustrative approval portal might look simple until it must reconcile historic records, handle delegated approvers and generate an audit trail. Those requirements change both the work and the testing.
Compare proposals on equivalent scope
- Check whether design, development and data migration are included.
- Identify licensing, hosting, payment and other third-party costs.
- Agree the number and purpose of review rounds.
- Define handling of new requirements and changed assumptions.
- Ask how acceptance, handover and support are priced.
Compare what each supplier will deliver and take responsibility for. A lower total may reflect a different solution or missing work, rather than a more efficient implementation.
Budget for ownership after launch
Allow for maintenance, account administration, dependency updates, monitoring, backups, user support and future changes. Agree source-code and data rights in the proposal, together with documentation and an exit route. A successful launch does not remove these obligations. We scope around the real operating requirement and identify external dependencies before committing to a delivery plan. For a defined next step, discuss the workflow and systems involved rather than requesting a price based only on a feature list.
Common questions
Can you give a fixed price?
A fixed price can be appropriate once scope, dependencies and acceptance criteria are sufficiently clear. Discovery may be needed first.
Does a longer timeline always mean more development cost?
No. Calendar time can include waiting for access, decisions or testing. A proposal should distinguish delivery effort from dependencies and review windows.