Counting screens or features is a poor way to estimate software. A chat experience may include identity, conversations, message delivery, notifications, moderation, history and privacy rules. A settings page might be small, or it might control permissions and complex policies. The estimation unit must describe a useful product capability and its assumptions, not a UI label.
This questionnaire groups common capabilities such as accounts, the core product workflow, payments, messaging, operations, reporting and data migration. Each selection represents a meaningful area of work. Within a capability, the range still varies with edge cases, scale, security, integrations and quality expectations.
Platforms are separate delivery surfaces. A responsive web application is different from a native mobile app, while staff-facing administration can often live inside the web product rather than require a separate platform. The tool calls this out so users can describe the actual launch target.
The resulting range is a planning prompt, not a quote. It uses broad effort bands and adds room for unknowns, particularly when complexity or existing data is involved. It does not inspect a codebase, validate requirements or account for every industry-specific constraint.
To sharpen the estimate, describe one primary user, the problem they need to solve, the successful end-to-end outcome, what can wait until a later release, and which data or services the product depends on. A focused discovery session can turn those assumptions into a deliverable scope and a more defensible schedule.