Define a release you can describe
Start with one sentence: which user needs to complete which task in the first release? Describe the starting point, steps and expected outcome. A concrete journey reveals the screens, data and rules involved.
For example, allowing a manager to invite a team and approve a request introduces multiple roles, invitations and a history of changes. This is a scoping example, not a quote: the cost still depends on the rules and context.
Separate the implementation costs
Ask for an estimate that distinguishes the main phases. You can then discuss a specific item without reopening the entire project.
- Discovery: assumptions, scope and validation criteria.
- Design: user journeys, interfaces and prototype.
- Development: features, administration and integrations.
- Acceptance: scenarios, fixes and verification.
- Launch: configuration, documentation and handover.
Identify the unknowns that change a quote
An external integration may be straightforward when the API is documented and access is available. It needs investigation when data is inconsistent or behaviour is poorly understood. The same line in a proposal can therefore represent very different work.
Data migration, access rights, billing and availability requirements also need clarification. For each unknown, ask whether it will be investigated before estimating or recorded as an assumption in the proposal.
Account for costs after launch
Separate the build price from monthly running costs. Hosting, external services, support and maintenance should remain visible even when initial volumes are low.
Build several usage scenarios: active users, storage, emails or calls to paid services. Ask what triggers a cost increase. An estimate should be revisited when its assumptions change.
Compare proposals on the same basis
Compare inclusions, exclusions, acceptance criteria and responsibilities. A lower quote may defer an integration or leave deployment to your team. That can be appropriate, provided it is understood.
The useful question is not only ‘how much?’ but ‘what will be usable, and how will we verify it?’ Before committing, clarify how scope changes work and how source code and access will be handed over.
What to prepare for an estimate
Gather a description of your users, a priority journey, the tools to connect and launch constraints. Put other ideas in a separate list. That distinction makes it possible to discuss a first release without losing sight of future plans.
We do not provide a universal price here: this guide prepares you for a project estimate rather than claiming a market average. Discovery makes it possible to price defined deliverables.