Two quotes for the same application can differ by a factor of five, and both can be honest. The difference usually comes from assumptions that were never written down: how many user roles, which systems must be integrated, how much traffic is expected, and who maintains the system after launch. Understanding what drives the cost makes those assumptions visible, and makes it possible to compare quotes and control the budget.
Cost Is Effort Multiplied by Rate
Almost every software estimate reduces to the same calculation: the effort needed to build and deliver the system, measured in person-days, multiplied by the rate of the people doing it. Rates vary with seniority and location, but effort varies far more, and effort is decided by scope. A lower rate rarely compensates for an underestimated scope, so most of the attention belongs on what is being built rather than on the daily rate.
Effort is not only programming. A realistic estimate includes requirements analysis, UI and UX design, development, testing, deployment, project management, and stabilisation after launch. When a quote is far below the others, check which of these activities it leaves out.
The Main Drivers of Custom Software Cost
| Driver | Lower effort | Higher effort |
|---|---|---|
| Features and workflows | A few screens with simple create, read, update, and delete | Multi-step approvals, calculations, and business rules with many exceptions |
| User roles and permissions | One or two roles with the same view | Many roles, per-branch or per-department data access, audit trails |
| Platforms | A responsive web application | Web plus native iOS and Android, or offline support |
| Integrations | None, or one well-documented API | ERP, payment gateway, legacy systems without documentation |
| Data migration | Starting with empty data | Importing years of records from spreadsheets or an old system |
| Non-functional requirements | Internal tool with a small number of users | High traffic, strict uptime targets, security or compliance audits |
Integrations and data migration are the drivers most often underestimated. An integration with a well-documented API may take days, while an integration with an undocumented legacy system can take weeks of investigation before any code is written. Old data almost always contains duplicates, inconsistent formats, and records that break the new system's rules.
Costs That Continue After Launch
The development budget is only part of the total cost of ownership. A system in production has running costs every month, and planning for them from the start prevents a well-built application from degrading because nobody budgeted for its upkeep.
- Infrastructure: servers or cloud services, database, storage, backups, domain, and certificates.
- Third-party services: payment gateway fees, email and SMS delivery, maps, and AI model usage, which often scale with transactions or users.
- Maintenance: security updates, framework and dependency upgrades, and bug fixes. Many organisations reserve a yearly budget equal to a meaningful share of the original build cost for this.
- Monitoring and support: someone has to notice and respond when the system fails, outside office hours if the business depends on it.
- Enhancements: once users work with the system, new requests follow. Budgeting for them avoids treating every improvement as an emergency purchase.
- App store fees and developer accounts for mobile applications.
Pricing Models: Fixed Price, Time and Materials, Dedicated Team
| Model | Works well when | Watch out for |
|---|---|---|
| Fixed price | Scope is clear, stable, and documented in detail | Change requests cost extra, and vendors add a risk margin to cover uncertainty |
| Time and materials | Scope will evolve as users give feedback | Requires active involvement and regular review of progress and spend |
| Dedicated team | Long-running product development with a continuous backlog | Needs a product owner on the client side to set priorities |
A common and practical combination is a fixed-price discovery phase that produces detailed requirements, designs, and an estimate, followed by fixed-price or time-and-materials development based on that output. The discovery phase costs a small fraction of the project and replaces guesswork with a scope both sides understand.
A simple example: a report that exports to Excel in any layout the user chooses can take several times longer to build than one with three fixed formats. Details like this need to be agreed before the estimate is made.
How to Reduce Cost Without Reducing Quality
- Start with a minimum viable product that covers the core workflow end to end, then add features based on real usage rather than assumptions.
- Use proven off-the-shelf services for problems that do not differentiate the business, such as authentication, payments, email delivery, and file storage.
- Prepare decisions before development starts. Waiting for answers on business rules stalls the team and is paid for in time.
- Name one decision-maker on the client side, so feedback is consistent and priorities do not change with every meeting.
- Do not cut testing, code review, or monitoring to save money. Those cuts reappear later as production incidents and rework that cost more than they saved.
What to Prepare Before Requesting a Quote
- 1Describe the business problem and the outcome you expect, not only the list of features. A good vendor may propose a simpler way to reach the same outcome.
- 2List the users and roles, and for each one the main tasks they need to complete in the system.
- 3List the systems the application must connect to, with whatever documentation exists for them.
- 4Estimate the number of users, transactions, and data volume, now and in two to three years.
- 5Share examples, sketches, or existing tools the team currently uses, including spreadsheets.
- 6State the budget range and the deadline, and which of the two is more flexible. This lets the vendor propose a scope that fits instead of a scope that has to be cut later.
How to Compare Quotes from Software Houses
Compare quotes by what they include, not only by the total. Check whether each one covers design, testing, deployment, documentation, and a warranty period after launch, who owns the source code, and how change requests are priced. A quote that breaks the work into modules with their own estimates is easier to discuss, and easier to trim, than a single number.
Ask how the vendor arrived at the estimate and which assumptions it rests on. A vendor that asks many questions before quoting is usually reducing risk for both sides. A vendor that quotes immediately from a one-page brief is either making assumptions you have not seen, or adding a margin large enough to absorb them.
Key takeaways
- Cost is effort multiplied by rate, and effort is driven by scope. Clarifying scope saves more than negotiating rates.
- Integrations, data migration, user roles, and non-functional requirements are the drivers most often underestimated.
- Budget for running costs after launch: infrastructure, third-party services, maintenance, monitoring, and enhancements.
- A short discovery phase before development turns a rough guess into a scope and estimate both sides understand.
- Compare quotes by what they include and which assumptions they make, not only by the total.
