Build the budget around scope, uncertainty and ownership

When a business receives a quote for a web application, the figure usually covers the visible work: designing screens, writing code, and deploying to a server. What that quote often does not cover is the full cost of making the system operational, compliant, and genuinely usable by real people doing real work.

These additional costs are not necessarily hidden in a deceptive sense. Many arise because the buyer and supplier have different assumptions about what sits inside the project boundary. A supplier might reasonably exclude data migration because the scope document did not mention an existing system. A buyer might assume that user training is included because, from their perspective, the system is not finished until staff can use it.

The practical problem is not bad faith from either side. It is that a development estimate typically answers the question "what will it cost to build this?" rather than "what will it cost to have this working in our business?" Those are different questions with different answers.

Where the gaps typically appear

Several cost categories tend to sit outside the initial build estimate. Third-party service subscriptions — payment gateways, mapping services, email delivery platforms, cloud hosting tiers — often have their own pricing that depends on usage levels the supplier cannot predict. Integration work with existing business software can appear straightforward until the reality of inconsistent data formats, undocumented API behaviours, or authentication quirks emerges during development.

Data migration is another frequent source of uncosted work. Moving records from a legacy system, a collection of spreadsheets, or a previous supplier's database requires analysis, cleaning, transformation, and validation. That effort depends entirely on the state of the source data, which is often unknown until someone examines it closely.

Legal and contractual costs — drafting or reviewing development agreements, data processing addenda, intellectual property assignment clauses, and terms for third-party service usage — are business expenses that sit alongside the technical work but rarely appear on a build quote.

Scenario: Replacing a spreadsheet with a customer portal

A business decides to replace an internal spreadsheet that tracks client orders with a proper web application. The build estimate covers the portal itself: login, order entry, status tracking, and a basic admin panel. During development, several questions arise that were not in the original scope. How do historical orders get into the new system? Who decides which fields are mandatory when the spreadsheet allowed anything? What happens to orders that are in a half-completed state in the spreadsheet? Each of these decisions requires someone's time, and the resolution often generates additional development work.

Scenario: Building an internal tool that connects to existing software

An operations team needs a custom dashboard that pulls data from their CRM and their accounting package. The initial estimate assumes both systems have well-documented APIs that return clean data. During integration, the team discovers that the CRM API rate-limits requests more aggressively than expected, the accounting package requires a specific authentication flow not mentioned in its public documentation, and some data fields contain free-text entries that need manual categorisation before they can be displayed meaningfully. The integration work expands, and so does the cost.

Scenario: A SaaS product preparing for its first commercial customers

A founder commissions a minimum viable product for a subscription-based service. The build covers core functionality, a basic payment connection, and a landing page. As launch approaches, new requirements surface. The payment provider needs specific compliance documentation. The terms of service and privacy notice need legal review. The hosting environment needs to be configured for multi-tenancy rather than single-tenant development. Each of these is a genuine project cost that was not visible at the estimate stage because the scope had not been defined in enough detail.

Environment and infrastructure costs

Development, staging, and production environments each carry costs. A supplier might include one production environment in the quote but charge separately for a staging environment that mirrors production — something most serious projects need. SSL certificates, domain configuration, database hosting, file storage, and content delivery networks all have their own pricing structures. These are not large line items individually, but they accumulate and they recur.

Testing beyond the happy path

Basic functional testing is usually included in a build quote. What is often excluded is the broader testing that a business-critical system actually needs: testing with realistic data volumes, testing across different browsers and devices, testing what happens when third-party services go down, and testing the behaviour of error states and edge cases. If the business wants a formal user acceptance testing process with documented sign-off, that effort may sit outside the supplier's standard workflow.

Treating the estimate as a fixed price without understanding the assumptions

An estimate is only as reliable as the information it is based on. If the requirements are vague, the estimate will contain assumptions — about data quality, integration complexity, user behaviour, and scope boundaries. The mistake is accepting the number without asking what assumptions sit behind it. A supplier who is willing to walk through those assumptions is usually easier to work with than one who treats the estimate as a black box.

Assuming all suppliers define scope the same way

One supplier's "build" might include discovery workshops, data migration planning, and a user acceptance testing phase. Another supplier's "build" might start with a finished specification and end when the code is deployed. Comparing quotes without aligning scope boundaries leads to poor decisions. The cheaper quote may simply be excluding work that the more expensive quote includes.

Leaving data migration as an afterthought

Data migration is often mentioned in passing during early conversations and then forgotten until late in the project. By that point, the source data has not been examined, the transformation rules have not been defined, and the validation criteria have not been agreed. The result is a rushed, under-resourced migration that becomes a source of delay and additional cost. Treating data migration as a workstream with its own analysis phase, rather than a minor task at the end of development, usually costs less in the long run.

Overlooking access, ownership and exit arrangements

Setting up repository access, ensuring source code ownership is properly documented, arranging access to hosting accounts, and agreeing what documentation will be produced are all tasks that take time. If they are not addressed during the project, they become costly and contentious when the business wants to move to a different supplier or bring the work in-house. These are not theoretical concerns — they are practical costs that arise when the arrangements are absent.

Key questions to put to a supplier before accepting a quote

  • What specific items are excluded from this estimate that you would expect to discuss separately?
  • What assumptions have you made about the quality and structure of our existing data?
  • How are changes to scope handled if we discover something during development that was not visible at the start?
  • What environments are included — development, staging, production — and what are the ongoing infrastructure costs for each?
  • What testing is included, and what would constitute an additional testing phase?
  • Who owns the source code, and how is that ownership documented?
  • What access will we have to repositories, hosting accounts, and third-party service dashboards?
  • What documentation will be produced, and in what format?

Limitations of planning

No amount of upfront planning eliminates all uncertainty. Some costs genuinely cannot be predicted because they depend on information that does not exist yet — the state of a legacy database, the behaviour of an undocumented API, or the precise way users will interact with a new workflow. The practical response is not to expect a perfect estimate but to build a project structure that surfaces unknowns early, allocates contingency, and makes decisions about additional cost visible and deliberate rather than accidental.

Review the budget as evidence changes

The most useful outcome of understanding hidden costs is not a larger budget. It is a more honest conversation between a business and a supplier about what the project actually involves, where the risks sit, and how both sides will respond when the inevitable unknowns appear.