A useful software budget starts with a defined outcome, not an industry average. A small internal tool and a customer-facing platform may both be described as “custom software”, yet require very different levels of design, integration, testing and ongoing operation. Compare quotations against the same scope before comparing their totals.
This guide uses an illustrative estimating model, not a survey of market prices or a Flowzelo quotation. Its purpose is to make the arithmetic and assumptions visible so you can ask better questions.
What actually determines the cost?
The number of screens is only one factor. A simple-looking screen may involve complicated permissions, data reconciliation or connections to unreliable external systems. Conversely, several straightforward information screens may be inexpensive to produce once a design system exists.
The most important questions are: who uses the software, what decisions it makes, which data it handles and what happens when something goes wrong? A tool used by three trained colleagues has a different operational context from a public service used by thousands of unfamiliar customers.
Write down the main workflow in plain language. For example: “A coordinator creates a job, assigns a colleague, records completion and sends a customer update.” Then identify exceptions such as reassignment, cancellation, duplicate records and failed notifications. These exceptions often reveal work omitted from an attractive initial estimate.
A transparent example budget
Imagine an internal job-management application with two user roles, one reporting view and one documented integration. Assume an agreed blended rate of £550 per delivery day solely for this example. This is neither a market benchmark nor an advertised Flowzelo rate.
| Work package | Illustrative days | At the assumed daily rate |
|---|---|---|
| Discovery and scope | 4 | £2,200 |
| User journeys and interface design | 5 | £2,750 |
| Core application development | 20 | £11,000 |
| Integration and import work | 6 | £3,300 |
| Testing and remediation | 7 | £3,850 |
| Deployment, documentation and handover | 3 | £1,650 |
| Total delivery effort | 45 | £24,750 |
Adding a 15% planning reserve gives £3,712.50, producing a planning total of £28,462.50 before any applicable VAT and external costs. A reserve is an allowance for uncertainty, not permission to add unlimited features.
The example excludes hosting, paid software licences, ongoing support, specialist independent assessments and major data cleansing. It assumes prompt feedback and a usable external API. If these assumptions fail, the estimate needs revisiting. Forty-five delivery days also does not mean forty-five calendar days: scheduling, reviews and dependencies affect elapsed time.
Separate build costs from operating costs
Ask for a full ownership model. The first release is one part of the financial decision; maintaining a working service is another.
Include hosting and storage, email delivery, authentication providers, API subscriptions, monitoring, backups, updates and support. Some costs depend on usage. An application that processes documents with an AI provider may have a very different cost curve from a brochure website serving static files.
For a three-year comparison, use:
Initial implementation + migration + 36 months of recurring costs + planned enhancement and exit costs.
Suppose a hypothetical service costs £150 a month to operate and has a £4,000 annual maintenance allowance. Over three years, those two items add £17,400. This is simple arithmetic, not an estimate for your project. Usage assumptions, supplier changes and the actual support agreement must be documented separately.
Why quotations can differ so much
One supplier may include discovery, testing and handover while another prices only feature construction. One may assume a clean import; another includes repairing inconsistent source records. These are scope differences, not necessarily differences in efficiency.
Compare what happens after launch. A short defect-remediation period is different from ongoing maintenance, and both are different from a guaranteed response-time support agreement. Ask who handles a third-party API change, an expired domain or a security update.
The NCSC’s maintainable-code guidance is a useful reference when discussing documentation and development practices. Treat maintainability as a deliverable with evidence, rather than a slogan.
Choose an appropriate commercial model
A fixed-price project works best when the boundaries and acceptance criteria are sufficiently clear. It should explain exclusions, change control and the circumstances that affect delivery. A fixed figure based on vague requirements can conceal uncertainty rather than remove it.
Time-and-materials can suit exploratory work if you agree reporting, spending limits and review points. A paid discovery followed by a scoped build is another option. The useful question is how the arrangement makes uncertainty visible and gives both parties a way to manage it.
Avoid choosing a model solely because it sounds safer. Request a sample progress report and understand when you can stop, what work you receive and how ownership is handled.
Reduce cost without removing essential controls
Reduce the first release to one complete, valuable journey. Use an existing identity or payment provider where appropriate. Reuse established interface patterns. Defer low-value customisation, elaborate reporting and speculative functionality until there is evidence for them.
Do not save money by leaving access control, backup restoration or deployment ownership undefined. For application security requirements, OWASP ASVS offers a reference framework that can help shape an agreed assessment scope.
Prepare sample data early. A representative anonymised export can expose inconsistent identifiers and missing fields before development depends on them. Decide who resolves data-quality issues and whether that work is included.
Questions to ask before accepting a quote
- What exact user journeys and exceptions are included?
- Which assumptions affect price and timing?
- What are the acceptance criteria and review milestones?
- Who pays for external services and owns the accounts?
- What testing, documentation and handover are included?
- How are changes assessed and authorised?
- What support is available after release, and under which terms?
- How can the business retrieve its data and move suppliers?
A strong quotation makes these answers easy to find. If you need help turning a broad idea into an estimate-ready brief, explore Flowzelo’s software consultancy or our custom software development service.
Sources and methodology
The budget and ownership calculations above are original illustrative planning examples. Technical delivery considerations are informed by the NCSC guidance and OWASP framework linked above. They do not establish UK market rates, project duration or a quotation for any particular business.
Last reviewed: . Guidance is general; project requirements and platform behaviour should be checked for your circumstances.
Explore the related Flowzelo service →