The real question is not what software costs. It is what your current setup is costing you.
Search "how much does custom software cost" and you'll find price ranges so wide they're useless for planning. "£10,000 to £500,000" tells you nothing. It's the equivalent of asking "how much does a building cost?" without specifying whether you're building a garden shed or a hospital.
Here is a more useful starting point. Before asking what custom software costs, consider what your current setup is costing you. The spreadsheets that three people maintain but nobody fully trusts. The five SaaS subscriptions that don't talk to each other. The manual processes that eat hours every week and still produce errors. The information that lives in someone's head rather than in a system.
If you've outgrown your current setup, you're already paying for it. The question is whether the cost of building something better is more or less than the cost of continuing as you are.
The real question: Custom software cost is not an abstract number. It's a comparison. What does it cost to build what you need, versus what does it cost to keep working around what you have?
This guide gives you honest numbers, realistic scenarios, and a framework for thinking about cost that goes beyond the initial build. It's written from the perspective of a small software consultancy (that's us) talking to UK business owners with 10 to 100 employees. No sales pitch. Just the maths, the trade-offs, and the things we wish every client knew before their first conversation about budget.
What Actually Drives the Cost
Most articles on software cost list the same factors: number of features, number of screens, design complexity, platform choice. That list isn't wrong, but it misses the point. Some of those factors have a significant impact on cost. Others matter far less than people expect.
The factors that genuinely drive cost are the ones that determine how much thinking the development team needs to do, not how many screens they need to build. A system with twenty simple screens can cost less than one with five screens that encode complex business logic.
| Factor | What people assume | What actually matters |
|---|---|---|
| Number of screens | More screens = more expensive | Simple CRUD screens are fast to build. Screen count alone tells you little. |
| Visual design | Polished design is a major cost | Clean design using established patterns is efficient. Custom illustration or animation adds cost, but most business software doesn't need it. |
| Business logic | Underestimated or not considered | This is the single biggest driver. Pricing rules, approval workflows, conditional logic, role-based permissions. The more rules, the more cost. |
| Integrations | "Just connect it to Xero" | Each integration adds days to weeks. API documentation varies wildly. Two-way sync is significantly harder than one-way. Connecting to HubSpot, Xero, or a legacy system each has its own complexity. |
| Data migration | Rarely considered at quoting stage | Moving data from old systems into new ones requires cleaning, mapping, validation, and testing. Messy source data multiplies the effort. |
| Compliance | "We need to be GDPR compliant" | GDPR adds concrete requirements: consent management, data access requests, right-to-erasure functionality, audit logging. These are real development tasks, not a checkbox. |
The practical implication is that two projects with the same number of screens can have vastly different costs. A simple internal dashboard that displays data from one source might take four weeks. A system that manages a multi-step approval workflow with role-based access, integrates with three external systems, and migrates five years of historical data might take four months.
When scoping a project, the honest conversation focuses on the complexity of the business rules, the number and nature of integrations, and whether data migration is involved. These three factors typically account for 70% or more of the total development effort. Everything else (screens, visual design, basic functionality) fills in around them.
Realistic Price Ranges for UK SMBs
UK developer day rates for experienced professionals typically fall between £400 and £750 per day. That range reflects the seniority, architecture thinking, testing, and long-term maintainability that a good developer brings. You're not paying for someone to type code. You're paying for someone to make the right decisions about structure, security, and scalability so the system works well for years, not months.
With that context, here are indicative price ranges for the kinds of projects UK businesses with 10 to 100 employees typically need. These are not quotes. They are ranges based on patterns we see repeatedly, and every project has its own specifics. But they give you a realistic anchor for planning.
An MVP approach can reduce the initial outlay significantly. Rather than building the complete system in one go, you identify the features that deliver the most value and build those first. A £50,000 project might start as a £20,000 MVP that proves the concept, then expand based on what you learn from real usage. This is often the most sensible way to manage both budget and risk.
To see what a custom web application looks like in practice, our development section walks through the technical detail of what these budgets produce.
The Five-Year View: Custom Software vs SaaS
The initial build cost of custom software is higher than any single SaaS subscription. That much is obvious. But software cost is not a one-year calculation. Over five years, the economics often look very different, particularly for businesses running on multiple SaaS subscriptions with per-user pricing.
Here is how the maths typically works for a UK business with around 30 employees, using four or five SaaS tools to manage operations.
| Year | SaaS stack (cumulative) | Custom build (cumulative) |
|---|---|---|
| Year 1 | £36,000 (£3,000/month across 4-5 tools, 30 users) | £55,000 (£45,000 build + £6,000 hosting/maintenance + £4,000 initial adjustments) |
| Year 2 | £75,600 (8% price increase, 2 new users) | £65,000 (£10,000 maintenance and hosting) |
| Year 3 | £119,200 (another increase, 3 more users, add-on module) | £75,000 (£10,000 maintenance and hosting) |
| Year 4 | £167,200 (continued growth, another price rise) | £90,000 (£10,000 maintenance, £5,000 feature additions) |
| Year 5 | £220,000 (5 years of compound growth in subscriptions) | £105,000 (£10,000 maintenance, £5,000 feature additions) |
The SaaS path starts cheaper but compounds. Per-user pricing means every new hire increases the cost. Annual price rises of 5 to 15% are standard across the industry (Salesforce, Monday.com, and similar platforms have all raised prices significantly in recent years). Add-on modules that seemed optional at first become necessary as the business grows. By year three or four, the monthly bill can be double or triple what it was at the start.
The custom path has a steep year-one cost, then flattens. Maintenance and hosting are predictable. Adding users costs nothing (there is no per-seat licence). New features are built on your schedule, at your discretion, and the system becomes more valuable over time rather than more expensive.
The break-even point: For businesses replacing multiple SaaS tools, the lines typically cross between 18 and 36 months. The exact point depends on how many tools you're replacing, how many users you have, and how fast the team is growing. After that crossover, custom software is cheaper every year, and the gap widens.
This is not an argument that custom software always wins on cost. For a three-person team using one or two SaaS tools at £50/month each, the numbers never cross. The comparison only favours custom development when the SaaS spend is significant, the business is growing, and the tools are creating friction that has its own cost. For the deeper economics of owning vs renting your systems, our dedicated guide examines the ownership question beyond pure cost.
Total Cost of Ownership: What Happens After Launch
This is the part of the cost conversation most agencies rush past. The build quote gets all the attention, but launch day is not the finish line. Software needs ongoing care, and understanding what that care involves (and costs) is essential for honest budgeting.
The industry rule of thumb is 15 to 25% of the initial build cost per year for maintenance. On a £50,000 build, that's £7,500 to £12,500 annually. But that figure is meaningless without understanding what it actually pays for.
-
Security patches and updates Frameworks, libraries, and server software receive regular security updates. Applying them promptly is non-negotiable.
-
Server monitoring and uptime Someone watches the logs, checks disk space, monitors performance, and responds when something goes wrong at 2am.
-
Framework and dependency updates Laravel, PHP, and supporting libraries release new versions. Keeping current means the system stays supported, secure, and compatible.
-
Minor feature adjustments Small changes based on real usage: tweaking a report format, adding a filter, adjusting a workflow step. The kind of refinements that make a good system better.
-
Support hours A pool of hours each month for answering questions, investigating issues, and providing guidance on how to use the system effectively.
Hosting costs sit alongside maintenance. For a typical UK-hosted business application, expect £100 to £300 per month depending on the scale, redundancy, and backup requirements. That covers the servers, database, SSL certificates, automated backups, and the infrastructure that keeps the application available.
What happens when maintenance is deferred
Some businesses treat maintenance as optional. It isn't. Skipping maintenance doesn't save money; it defers cost and adds risk. Here is the pattern we see repeatedly.
In the first year without maintenance, things seem fine. Security patches go unapplied, but nothing visibly breaks. In year two, the framework falls behind by a major version. Some library updates become incompatible. Small bugs accumulate. In year three, the system is running on unsupported software. Security vulnerabilities go unpatched. Making changes becomes harder because the codebase has drifted from current standards. By year four or five, the business faces a choice between an expensive upgrade (often costing more than the original build) or a complete rewrite.
A well-maintained Laravel application can run for a decade or more. The maintenance cost is real, but it is predictable and far cheaper than the alternative. For a fuller picture of what ongoing software maintenance involves and why it matters, our dedicated guide goes into detail.
How to Structure the Investment
Spending £30,000 to £80,000 on software for the first time is a significant decision. It should feel significant. But it doesn't need to feel like a leap into the dark. The way you structure the investment determines how much risk you take on and how much control you retain.
Pricing models
Three models cover the vast majority of SMB software projects. Each has its place.
Fixed price works when the scope is well-defined and unlikely to change. You know exactly what you'll pay. The trade-off is that changes to the specification usually require a formal change request process, which adds overhead. Best suited to projects where you've done thorough discovery first and the requirements are clear.
Time and materials (T&M) works when requirements are likely to evolve. You pay for time spent, and the scope can shift as you learn. The trade-off is that you carry the budget risk: if the project takes longer, you pay more. Best suited to iterative projects where flexibility matters more than a fixed price. A 15 to 20% contingency buffer in your budget protects against scope creep.
Retainer works for ongoing development after launch. A fixed monthly budget for continuous improvements, support, and feature additions. Predictable, flexible, and well-suited to the post-launch phase when the system is live and evolving based on real usage.
The recommended approach: phased delivery
For most first-time buyers, the smartest structure is a phased approach. It manages risk by breaking the investment into stages, each with its own deliverable and decision point.
Discovery (£2,000 to £5,000)
A short, focused engagement that produces a technical specification, a realistic budget, and a clear understanding of what you're building and why. This is the cheapest insurance you can buy. Spending £3,000 to de-risk a £50,000 decision is a straightforward calculation. At the end of discovery, you have a document you can use to compare quotes, brief other agencies, or decide not to proceed at all.
MVP build (core value first)
Build the features that deliver the most value. A focused first release that your team can start using. This validates the approach with real users and real data before committing to the full scope. Typically 40 to 60% of the total budget.
Iteration (expand based on real usage)
Add features based on what you learn from using the MVP. Real usage always reveals priorities that looked different on paper. This phase is where the system becomes genuinely yours, shaped by how your team actually works rather than how you imagined they would.
This approach means you never commit the full budget upfront. Each phase ends with a working deliverable and a clear decision about whether to proceed. To see how our engagement process works, our working-with-us page walks through the practical details.
When Custom Software Is the Wrong Answer
Not every business needs custom software. In some situations, building is genuinely the wrong decision, and knowing that upfront saves everyone time and money. Here are the scenarios where you should not build.
Being honest about these situations is not false modesty. It's practical. A business that builds when it shouldn't wastes money and time. A business that waits until the need is genuine builds the right thing. For the broader build-vs-buy decision framework, our dedicated guide covers this question in full.
How to Compare Agency Quotes
When you send a brief to three or four agencies, the quotes you receive will vary wildly. One comes back at £18,000, another at £55,000, a third at £90,000. The natural instinct is to compare the bottom-line numbers. That instinct will lead you astray, because those numbers rarely describe the same thing.
Here is what to look for when comparing quotes, beyond the total price.
And the warning signs.
UK-Specific Factors: VAT and IR35
Two UK-specific considerations affect the real cost of custom software development. Neither is widely discussed, but both are financially relevant.
VAT recoverability. If your business is VAT-registered, the VAT charged on software development services is input VAT and can be reclaimed. A £60,000 + VAT project carries a headline cost of £72,000, but the effective cost to a VAT-registered business is £60,000. This applies to development, maintenance, and hosting services. It's a straightforward 20% effective reduction on the real cost.
IR35 and engagement models. Hiring a freelance developer directly exposes your business to IR35 compliance risk and administrative overhead. HMRC's employment status rules can be complex to navigate, and getting them wrong carries penalties. Working through an established agency or consultancy simplifies the engagement: the agency handles its own compliance, and you have a clear commercial contract for services delivered.
Note: This is practical guidance, not tax advice. Confirm VAT treatment and IR35 implications with your accountant for your specific situation.
Making the Decision
You now have enough information to have a grounded conversation about budget, whether that's internally with a business partner or board, or externally with a development agency. You know what drives cost, what the realistic ranges look like, and how the five-year economics work. You understand total cost of ownership, not just the build quote. And you know the situations where the right answer is not to build at all.
The cost of custom software is real. But so is the cost of not having it: the hours lost to workarounds, the subscriptions that compound, the growth that's harder than it needs to be. For most UK businesses spending more than £2,000 a month on SaaS tools that don't quite fit, custom software pays for itself within two to three years and keeps paying after that.
A discovery phase (£2,000 to £5,000) is the lowest-risk way to start. You get a specification, a realistic budget, and a clear picture of what's involved before committing to the full build. If the numbers don't work, you've spent a small amount to find that out. If they do, you proceed with confidence.
Whether you're thinking about building the operational capacity to grow without the stress growing with it or exploring the kinds of operational systems this investment supports, the next step is the same: a conversation.
Start with a conversation, not a commitment
A 30-minute call is enough to talk through your situation, understand whether custom software makes sense, and get a realistic sense of cost.
See how we work together →