A software estimate is a model of work, risk and uncertainty. Two projects with the same screen count can differ by multiples when one has clean data and clear rules, while the other hides exceptions, manual workarounds and integrations nobody documented. The useful question is not “what is the price per screen?” but “what has to be true for this system to work?”
The short answer
Cost is driven by people, time and risk: discovery and business analysis, interface and system design, engineering, testing, security, deployment and the support that follows. Infrastructure is usually a smaller line item than the decisions that determine how much engineering the product needs.
What changes an estimate
- Scope clarity: written rules, exceptions and acceptance criteria versus a broad idea.
- Integrations: each external system adds authentication, error handling, retries and monitoring.
- Data: migration, cleaning, ownership and quality checks often take longer than the new interface.
- Permissions and workflow: roles, approvals, audit trails and edge cases multiply combinations.
- Security and compliance: payment, personal data or regulated information changes the design.
- Quality expectations: accessibility, performance targets, browser support and test depth.
- Delivery model: fixed scope, phased delivery or an embedded team changes planning overhead.
- Long-term ownership: documentation, handover and maintenance are part of the total cost.
A practical way to budget
- Start with a discovery step that produces a scope, a risk list and acceptance criteria.
- Prototype the riskiest workflow before estimating the whole product.
- Split delivery into increments that each produce something usable and testable.
- Keep a contingency for unknowns instead of pretending the first estimate is exact.
- Budget for operation, support and change after launch, not only for the first release.
What we need to estimate your project
- The business outcome and the people who will use the system.
- The current process, including manual steps and exceptions.
- Systems that must be integrated and who owns their APIs.
- Data sources, volume, quality and retention requirements.
- Security, privacy and access constraints.
- Target date, budget range and the decision process on your side.
What we will not do
We will not publish a fake price list or pretend that every project fits a template. We will explain the trade-offs, show what is included and estimate after we understand the problem. If the scope is still unclear, the honest next step is discovery, not a guess.
If you want to compare approaches, read how to choose a software development partner or discuss your project.