Specify a complete journey
Start with the primary user and the job they should finish. Include authentication where needed, the required data, the successful path and what happens when something fails. A list of screens can hide a large amount of integration and operational work.
Separate first-release requirements from later ideas. For a B2B portal, a useful first release might be submitting a request, reviewing it and seeing its status. Multiple business units, complex reporting and additional integrations may belong in later phases. This is a scoping example, not a standard package.
What belongs in the proposal
| Area | Questions to answer |
|---|---|
| Product | Which users, roles, workflows, screens and supported devices are included? |
| Integrations | Which systems, access permissions, test environments and failure states are covered? |
| Data | Who supplies content and migration data, and what cleanup is included? |
| Quality | Which browsers, accessibility checks, security controls and acceptance cases will be tested? |
| Commercial scope | What is included, excluded, separately billed or dependent on a client decision? |
| Release | Who approves launch, owns the accounts and can roll back a failed change? |
| Handover | What code, documentation, access and operational knowledge are transferred? |
Separate build cost from running cost
Ask for separate treatment of discovery, implementation, third-party subscriptions, cloud usage, migration and support. If AI is involved, identify model usage and evaluation costs. Provider fees and consumption can change even when the application scope stays the same.
A quote should state assumptions about users, data volume, integrations and availability requirements. When these are unknown, use discovery or a technical spike to reduce uncertainty instead of presenting a precise figure with no basis.
Make acceptance observable
Replace ‘the dashboard works’ with a scenario: an authorized reviewer can open a submitted request, change its status and see that status reflected for the requesting user. Include permission failures, validation errors and unavailable dependencies.
Agree how defects are distinguished from new scope. A missing behavior in an approved acceptance case is different from an additional role or an unplanned integration. Recording that distinction protects both the budget and the working relationship.
Handover is part of the release
- Access to the agreed repository and a documented local setup.
- An inventory of cloud and third-party accounts with responsible owners.
- Deployment instructions, environment configuration guidance and a recovery path.
- Database and file-storage responsibilities, including agreed backup and restore procedures.
- Known limitations, outstanding work and acceptance results.
- Support coverage, escalation contacts and the process for future changes.
What to bring to the first conversation
Bring a rough workflow, the systems it touches, the intended users and any constraints on launch. Existing screenshots or a manual process are often more useful than a long feature wish list. State a budget constraint privately if it affects the options; there is no need to publish it.
Use the downloadable scope and handover checklist to compare proposals on the same basis. Our custom software engagement explains how we turn that information into an agreed release and quote.
