Article 03
Estimating a software project: why screen count is not enough
Understand what changes scope, timeline and budget across workflows, roles, integrations, migration and go-live readiness.
Visible
10
Screens
Must be designed
Example situation
Start with the people using the system
Only ten screens, so why is the estimate not immediate?
One approval screen may contain roles, states, notifications, attachments, history and ERP integration. Complexity lives in rules and data behind the screen, not its visible size.
Summary for business and everyday users
Estimating a software project: why screen count is not enough
Estimate business flows, not screen lists.
Integrations, migration and permissions often change effort substantially.
Start with discovery and a first phase that has a closed boundary.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 03
01 / Complexity drivers
Invisible work often takes longer than visible screens
A system needs data models, rules, permissions, validation, error handling, tests, deployment and operation. Similar-looking screens can require very different effort when these conditions differ.
Evidence to inspect
- Roles and permissions
- States and exceptions
- External integrations
- Legacy migration
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Complexity drivers
01Invisible work often takes longer than visible screens
A system needs data models, rules, permissions, validation, error handling, tests, deployment and operation. Similar-looking screens can require very different effort when these conditions differ.
- Roles and permissions
- States and exceptions
- External integrations
- Legacy migration
- Security, availability and support level
02 / Estimate as a range
02An assumption-based range is better than a falsely precise number
Early estimates should show inclusions, exclusions, risks and information needed to narrow the range. A single number before workflow and integration discovery hides uncertainty and often causes later scope or budget changes.
Example phasing
Start with one approval workflow
Phase 1 covers roles, form, approval, notification and a core report. Complex integrations and analytics move to Phase 2 after the first flow is validated.
03 / A finishable boundary
03A good scope defines what done means
Each flow needs users, start and end, inputs, outputs, failure cases and agreed acceptance criteria, plus clear responsibility for data, approval and post-launch ownership.
Tech Leads should separate functional scope from non-functional requirements such as latency, availability, security, audit, backup and observability.
Checklist before action
Identify core flows
Name roles and owners
List integrations
Review migration data
Define non-functional requirements
Write acceptance criteria
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Product & Engineering
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.