Software project cost: what a screen count leaves out

Why can two software proposals with the same number of screens have very different prices? In one, a customer record contains a name and phone number. In the other, it involves branch permissions, imported history, approval rules and connections to external systems. The screen count looks similar, but the problem the delivery team must solve is not. Understanding software project cost means making that hidden work visible.

Comparing only the final price conceals important differences. One proposal may include cleaning historical data while another assumes the business will supply a ready-to-import file. One team may allow for post-release observation while another defines delivery as handing over files. A meaningful comparison starts with shared assumptions and a shared understanding of what completion includes.

Describe the job rather than the screen

“Build a customer screen” is a weak basis for estimation. Who creates the customer? What happens when the same person appears again? Which fields can each role change? Can branches see one another’s records? If the brief leaves these questions unanswered, suppliers fill the gaps with their own assumptions. Different assumptions produce different estimates.

Describe a workflow through its starting point and outcome. An enquiry is recorded, assigned, completed and resolved. Identify the rule, notification and retained information at each transition. Discuss exceptions as well: incorrect assignment, cancellation, reopening or simultaneous edits. Much of the complexity that affects cost appears between the visible screens.

This does not require settling every detail before work begins. Distinguish important unknowns from presentation preferences that can be decided later. An unresolved approval rule has different consequences from an undecided button colour. Spend discovery effort where the answer could materially change the work, rather than giving every question equal attention.

A delivered spreadsheet is not necessarily usable data

Receiving an existing file does not establish that its contents are ready for migration. The data may contain duplicate customers, missing dates, contradictory statuses or abandoned fields. Define migration through its sources, transformation rules and validation method. State which data-quality decisions the business will make and which tasks the development team will perform.

Imagine a fictional service business with separate customer and job-history files. Linking each historical job to the correct customer may require more than an upload button. Ambiguous matches need a review process, duplicate records require decisions and the resulting import needs checking. Leaving these activities out of the estimate does not make them disappear.

Use representative sample data to investigate the work. Selecting only clean rows hides the effort associated with real records. Include missing dates, duplicates and inconsistent formats where relevant. Agree an appropriate method for sharing information, and avoid circulating unnecessary personal data simply to obtain a proposal. The estimate should describe what the sample established and what remains uncertain.

Integration cost extends beyond making a connection

A successful connection to an external system does not establish that information will flow correctly over time. Decide which system creates each piece of data, how often exchanges occur, how failed attempts are retried and how unsuccessful records become visible. Missing documentation or the absence of a test environment can increase uncertainty in the estimate.

An integration line item should say more than the name of the service. Specify the operations, authorisation arrangements and business rules involved. Creating an order is a different scope from managing returns, partial fulfilment and cancellation. Show supplier charges and applications the business must complete separately from the development fee, so they do not become unexpected extras.

A limited technical experiment can clarify a critical connection. Its purpose is to test access or a consequential assumption, not to complete the entire integration under another label. The result should explain which part of the estimate is now better understood and which questions still require an answer. That evidence is more useful than a blanket statement that integration is possible.

Permission rules create work behind the interface

Showing different menus to administrators and ordinary users is only the visible part of authorisation. Data access and permitted actions must also be enforced by the application. Rules based on branch, team or record ownership can make the scope more involved. Changes in a user’s role may also require existing access to be reconsidered.

Sensitive operations may need an approval step, an additional check or an audit history. Decide which changes are recorded, what those records contain and who can inspect them. Adding these requirements at the end with the assumption that they were already included in security creates avoidable disagreement. Linking them to acceptance criteria exposes both implementation and verification effort.

Retention and deletion behaviour also deserve an explicit decision. The business may need specialist advice about obligations that the software team cannot infer automatically. Translate agreed requirements into rules about when records are deleted, retained or anonymised. Where uncertainty remains, describe it as an assumption in the proposal rather than silently choosing a behaviour.

Testing needs its own allowance

Calculating development effort and using whatever time remains for testing produces a fragile budget. Verifying important journeys, retesting corrections and preparing user acceptance all require work. Multiple roles, devices or languages can change the scope. Assess which combinations matter most instead of assuming that every possible combination has equal business importance.

Acceptance criteria make proposals easier to compare. Replace “the report will work” with a description of the filters, a calculation example and the required permission behaviour. Identify who provides test data and who represents the business in acceptance sessions. Explain how delayed answers affect the schedule. Cooperation has a practical cost when decisions arrive too late for planned work.

Interface design has a similar distinction. Adapting existing components differs from conducting substantial research, building prototypes and observing users complete tasks. Discuss which approach the problem needs. The most extensive process is not necessary for every project, but expecting the results of a service that the proposal does not include creates a mismatch from the beginning.

Separate development cost from ownership cost

Hosting, storage, email delivery and external services can continue generating charges after launch. State which accounts belong to the business and which fees are paid directly to providers. Usage-dependent charges should not be presented as permanently fixed. Make the traffic, record-volume or file-storage assumptions behind the calculation visible so the business can revisit them later.

Maintenance, support and further development can be evaluated as separate categories. Updates, monitoring, backups and user questions do not end when the application is published. Discussing them alongside the build helps the business understand its first-year commitments. If maintenance is included in the headline price, explain the period, coverage and limits rather than leaving inclusion open to interpretation.

Source code, usage rights and handover terms also affect the comparison. What will the business receive if it chooses another maintenance team? Unclear deployment instructions, account access or documentation can create future dependency despite an attractive initial price. The purchasing decision should consider the ability to operate and change the product, rather than ending with the first invoice.

Fixed price and changing scope need a clear relationship

A fixed fee works best against a sufficiently defined deliverable. Requesting certainty while major questions remain unanswered means the uncertainty must be accommodated somewhere in the proposal. A short discovery or prototype exercise can resolve consequential questions. Give that exercise its own outputs and limits so preparation does not become an indefinite activity without a decision point.

A time-based arrangement places more emphasis on budget visibility. Show completed work, remaining priorities and changes to the forecast at useful intervals. Flexibility does not require the business to learn about its spending only at the end of the period. Both commercial approaches need a documented route for approving changes and understanding their effects.

When a new request arrives, evaluate its impact on the agreed goal. The business can add budget, defer another item or narrow the request. Assuming every addition fits the same date and price eventually makes the plan unusable. Discussing the trade-off is more constructive than either rejecting every change or accepting it without explaining the consequences.

Build a short comparison record

Review proposals under common headings: workflows, migration, integrations, permissions, testing, release, maintenance and handover. For each heading, record what is included, what the business supplies and which questions remain open. A lower line-item price may reflect a narrower responsibility rather than a more efficient way to deliver the same outcome.

Assign an owner to important assumptions. Who will obtain external-system access, approve the sample data and make the acceptance decision? The budget then becomes a working agreement throughout delivery instead of a document used only during purchasing. Beginning custom software planning with real examples of the work produces a more useful comparison than negotiating against a screen list alone.

The record should also make exclusions easy to find. If historical attachments are not being migrated or a particular workflow is deferred, state that alongside the relevant deliverable. An exclusion buried in a general note can be missed by the people preparing for launch. Clear boundaries let the business plan temporary arrangements and decide whether additional work is genuinely necessary.

Frequently asked questions

Is pricing by screen count always wrong?

A screen list can help start a scope discussion, but it should not be the only measure. Similar screens may involve very different rules, permissions and connections. A reliable estimate needs an explanation of the work users complete and the important exceptions the application must handle. The count alone does not reveal those differences.

Why is a firm price sometimes unavailable after the first meeting?

Unknown data quality, integration conditions or acceptance requirements can make a precise figure misleading. An initial assessment may provide a range with explicit assumptions. As consequential questions are answered, the estimate can become more specific. The supplier should explain what information is needed and how it will affect the decision, rather than simply refusing to discuss cost.

Is using an existing platform always cheaper?

It may reduce initial development effort, but licensing, adaptation, integration and operating costs still matter. The fit between the business requirement and the platform is decisive. Extensive modification can change the overall economics. Evaluate ownership cost over a relevant period and identify limitations that might become significant as the business changes.

Where should we start if the budget needs to be reduced?

Consider deferring lower-priority features and narrowing the main workflow to a usable first release. Leaving essential verification, access control or recovery arrangements undefined creates a different kind of exposure. A smaller deliverable with clear acceptance criteria may be more valuable than many partially completed features. Decide which business outcome the available budget must protect.

How can we compare a low quotation with a much higher one?

Align deliverables, assumptions and responsibilities before comparing totals. Check migration, supplier fees, testing, support, code ownership and handover. Ask both teams to answer the same unresolved questions. Without that alignment, a difference in scope can look like a difference in price, making the apparent saving difficult to assess and the final purchasing decision less reliable.