A familiar conversation plays out in meeting rooms across London. Someone arrives with an idea for a new software platform, explains it enthusiastically over coffee and then asks the apparently simple question:
How much will it cost?
There is often a short pause - roughly the same pause a builder gives you when you suggest moving a load-bearing wall.
That pause is not evasiveness. Asking for a bespoke software price before discussing the requirements is rather like asking what a house costs without mentioning its size, location or whether you would like a cinema in the basement.
The honest answer is that bespoke software development in the UK can cost anywhere from tens of thousands of pounds to several hundred thousand, depending on what is being built, how it connects to the wider business and how critical it will be once launched.
A typical UK bespoke software project may cost between £25,000 and £250,000+, with scope, technical complexity, integrations, security requirements and ongoing support having the greatest influence on the final price.
Typical bespoke software costs in the UK
Although every project is different, indicative price ranges can help with early budgeting.
Broadly speaking, UK businesses might expect the following:
- £15,000–£40,000 for a focused prototype, internal tool or relatively simple minimum viable product
- £40,000–£100,000 for a production-ready business application with user accounts, workflows, reporting and selected third-party integrations
- £100,000–£250,000 for a complex platform supporting multiple user groups, sophisticated business logic, high data volumes or several external systems
- £250,000+ for business-critical software, large digital products, extensive automation or platforms requiring continuous development
These are planning figures rather than catalogue prices.
Two applications that look remarkably similar on screen can require very different amounts of work underneath. A straightforward customer portal connected to one modern API is not the same engineering challenge as a portal exchanging data with six ageing systems, each of which appears to have been documented on a Post-it note in 2009.
The most useful way to understand cost is therefore to look at the factors behind it.
Project scope: what must the software actually do?
Scope is usually the biggest influence on bespoke software pricing.
Every feature requires some combination of planning, design, development, testing and deployment. More features mean more work, but complexity matters just as much as quantity.
Consider a stock management system.
At its simplest, users might:
- Add products
- Update quantities
- View reports
A more advanced version could:
- Track stock across several warehouses
- Support barcode scanning
- Trigger automated purchasing rules
- Forecast future demand
- Apply different permissions by role or location
- Synchronise with an ecommerce platform and accounting package
- Maintain a full audit trail
Both systems could reasonably be described as stock management software. Their development costs would be nowhere near identical.
This is why a good software partner will challenge requirements rather than merely accept a long feature list.
Questions worth asking:
- Which capabilities are essential at launch?
- Which can wait?
- Is a feature solving a genuine operational problem?
- Has it appeared because somebody saw it in another product?
At Atreon, we generally favour defining the smallest valuable first release and building from there.
This approach:
- Lowers initial risk
- Gets software into users’ hands earlier
- Creates room to learn before committing the entire budget
Discovery and planning are part of the investment
Businesses sometimes view discovery as an optional preamble before the "real" development begins.
In practice, it is one of the best ways to protect the budget.
A discovery phase may include:
- Stakeholder workshops
- Process mapping
- Technical investigation
- User research
- Initial product roadmap creation
The aim is to turn a promising idea into a buildable plan.
It also helps uncover awkward details while they are still inexpensive to address.
For example, a team may assume that customer records are held neatly in one database.
Discovery reveals that the data actually lives across:
- A CRM
- Several spreadsheets
- An old desktop application known only as The System
Suddenly, data migration and reconciliation need proper attention.
Depending on the project, discovery might cost a few thousand pounds or represent a larger standalone phase.
That is not money spent delaying development.
It is money spent avoiding avoidable development.
Integrations can be simple, difficult or surprisingly theatrical
Most modern software does not operate alone.
It may need to communicate with:
- Payment providers
- Accounting systems
- CRMs
- Mapping services
- Identity platforms
- Logistics tools
- Industry-specific databases
Well-documented modern APIs can make these connections relatively efficient.
Older or proprietary systems can require considerably more work.
Integration costs tend to rise when:
- Documentation is incomplete or outdated
- Data formats are inconsistent
- External systems impose restrictive usage limits
- Information must synchronise in both directions
- Failures require complex recovery processes
- Testing environments are unavailable
- Third-party suppliers are slow to respond
There may also be direct third-party charges.
Examples:
- Payment gateways taking transaction fees
- Mapping platforms charging by usage
- Commercial APIs requiring monthly licences
Those costs sit outside the development budget but still belong in the overall financial picture.
Integration work should therefore include more than making two systems exchange a successful test message.
Production software must handle:
- Timeouts
- Duplicate records
- Invalid data
- External services becoming unavailable
Because external systems rarely choose a quiet Tuesday afternoon to fail.
Security, privacy and compliance affect the architecture
Security is not a decorative feature added shortly before launch.
The sensitivity of data, consequences of a breach and regulatory requirements all influence how software should be designed.
A basic internal scheduling tool has different requirements from a healthcare platform handling sensitive information or a financial application authorising payments.
Additional security measures may include:
- Multi-factor authentication
- Single sign-on
- Role-based access controls
- Encryption in transit and at rest
- Detailed audit logging
- Automated vulnerability scanning
- Independent penetration testing
- Secure backup and disaster recovery arrangements
- Formal retention and deletion policies
UK GDPR obligations may also affect:
- Consent handling
- Privacy notices
- Data exports
- User access rights
- Data deletion processes
These measures increase initial costs, but treating security lightly is a false economy.
Retrofitting access controls or audit trails into a mature application is considerably harder than designing them properly from the beginning.
User experience involves more than making it look smart
Design is another variable that is easy to underestimate.
Bespoke software needs to look credible, but its more important job is making complicated tasks feel manageable.
A simple internal application used by a trained team may only need:
- A modest interface
- A reusable design system
A public-facing digital product competing for customers may require:
- User research
- Prototype testing
- Accessibility work
- Detailed visual design
The number of supported devices matters too.
A responsive web application working across:
- Desktop
- Tablet
- Mobile
requires more design and testing than a desktop-only tool.
Native iOS and Android applications add:
- Platform considerations
- App store processes
- Device testing
Investing in usability often generates savings elsewhere.
Clear workflows reduce:
- Training requirements
- Mistakes
- Support requests
The development team and delivery model influence price
Bespoke software is rarely produced by one developer working through a checklist.
Depending on the project, the delivery team may include:
- Product specialists
- Business analysts
- UX/UI designers
- Front-end developers
- Back-end developers
- Cloud engineers
- DevOps specialists
- Quality assurance specialists
- Security consultants
The balance changes throughout the project.
Early stages may involve more:
- Research
- Design
- Planning
Later phases focus more on:
- Engineering
- Testing
- Deployment
UK development rates are generally higher than offshore suppliers.
However, price alone does not reveal total delivery cost.
Communication gaps, unclear ownership and weak quality assurance can turn a cheap hourly rate into an expensive project.
A capable team should:
- Reduce uncertainty
- Identify risks early
- Make sensible technical decisions
- Communicate clearly
Decision-makers should not need a computer science degree to understand where the budget is going.
Data migration can become a project of its own
Replacing an existing system often means historical information needs to move.
This sounds straightforward until somebody opens the old database.
Data may be:
- Incomplete
- Duplicated
- Stored differently across departments
- Hidden in free-text notes
Migration work can involve:
- Auditing source data
- Mapping old records
- Cleaning duplicates
- Writing migration scripts
- Validating results
- Planning rehearsals
- Creating rollback procedures
The volume of data is not always the main issue.
Ten million clean records can be easier to migrate than fifty thousand inconsistent ones.
Testing and quality assurance deserve a visible budget
Testing should not be whatever time remains before launch.
Reliable bespoke software needs systematic checks throughout development.
Quality assurance can include:
- Automated unit tests
- Integration testing
- Browser testing
- Device testing
- Performance testing
- Accessibility reviews
- User acceptance testing
Business-critical platforms may also require:
- Load testing
- Security assessments
- Formal release controls
Experienced suppliers include testing in their estimates rather than presenting it as an optional extra.
They also account for less visible engineering work:
- Deployment pipelines
- Monitoring
- Logging
- Backups
- Recovery procedures
None of this makes for an exciting launch screenshot.
It does become exciting when something goes wrong.
Hosting, support and ongoing development
The cost of bespoke software does not stop at launch.
Once software becomes useful, it needs to remain:
- Secure
- Available
- Compatible
- Maintained
Ongoing expenditure may cover:
- Cloud hosting
- Data storage
- Monitoring
- Backups
- Security updates
- Technical support
- API costs
- Performance improvements
- New features
Support requirements vary.
A public ecommerce platform processing payments has very different needs from an internal reporting system.
As a broad planning assumption:
Annual maintenance and support may represent 10–25% of the original development cost.
The actual figure depends on:
- Service levels
- Infrastructure
- Support requirements
- Development pace
Successful bespoke software is usually treated as a long-term product rather than a one-off purchase.
Fixed price or time and materials?
Fixed-price projects
Best when requirements are:
- Stable
- Clearly defined
Advantages:
- Budget certainty
Disadvantages:
- Changes usually require additional approval and cost
Time-and-materials projects
Charges based on actual delivery time.
Advantages:
- Flexible
- Suitable for evolving products
Disadvantages:
- Final costs are less predictable
Many projects benefit from a hybrid approach:
- Fixed-cost discovery phase
- Iterative development against an agreed budget
This provides financial control without pretending every detail can be predicted months before users see the product.
How to control bespoke software costs without cutting corners
Cost control is not about choosing the cheapest developer.
It is about spending deliberately.
Start by defining the business outcome.
Understand whether the goal is to:
- Reduce administration
- Increase sales
- Improve customer service
- Replace legacy systems
Then:
- Prioritise a valuable first release
- Test assumptions early
- Involve users throughout development
- Investigate integrations and data early
- Agree decision-making processes
- Keep a contingency budget
- Measure outcomes after launch
A trustworthy software company should also say when an off-the-shelf product is the better option.
Bespoke development earns its place when existing tools cannot support an important process, competitive advantage or growth plan.
Asking for a useful software estimate
To obtain a meaningful estimate, provide context rather than a rigid wish list.
Explain:
- The problem
- The users
- Existing systems
- Expected timescale
- Fixed constraints
Useful questions include:
- What assumptions is the estimate based on?
- Which items are excluded?
- How will scope changes be handled?
- Who owns the source code and intellectual property?
- What testing and security work is included?
- What support is available after launch?
- How will progress and spending be reported?
At Atreon, we use early conversations and discovery to understand both the commercial objective and technical reality.
That allows us to recommend a sensible route:
- Focused first releases
- Phased modernisation
- Larger bespoke builds
So, what should your business budget?
For an initial business case:
£25,000–£100,000 is a realistic planning range for many focused UK bespoke software projects.
More complex platforms frequently move beyond £100,000, while enterprise-scale or highly regulated systems can require several hundred thousand pounds across multiple phases.
The better question is not:
What will the software cost?
It is:
What value must it create?
A £75,000 platform removing £150,000 of annual administration is a very different proposition from a £30,000 application that nobody uses.
Good bespoke software should:
- Solve a valuable problem
- Fit the organisation properly
- Continue earning its place after launch
With clear priorities, honest discovery and an experienced delivery team, the cost becomes understandable and, more importantly, investable.