Almost every supplier calculates bespoke software development cost the same way underneath: estimated days of work, multiplied by a day rate, with some allowance for uncertainty. What differs is how honest the day estimate is and what the rate pays for.
The day estimate comes from breaking your system into features, then each feature into tasks: screens, database changes, business rules, tests, deployment. A careful supplier shows you that breakdown. A less careful one gives you a single number, which makes it impossible to see where money goes or what to cut.
The day rate pays for the developer's time plus everything around them. In a UK software house that includes salaries at UK levels, office space, project managers, sales staff and profit. In a remote freelance team it covers mostly the people writing the code. Neither is wrong, but you should know what you are buying.
On top sits contingency: an allowance for the things nobody can foresee on day one. Then support, which begins the day the system goes live and continues for as long as you use it. A realistic budget includes all four.
UK, nearshore and India day rates: what does each buy?
UK software houses charge the highest day rates, nearshore teams in Eastern Europe or Portugal usually sit in the middle, and India-based teams typically charge the least for comparable skills. Quotes vary widely within each group, so compare what is included rather than the headline rate alone.
A UK rate often covers roles you may or may not need: a dedicated project manager, a business analyst, a designer, a tester and someone to run workshops in your office. For a large system with many stakeholders, those roles earn their keep. For a focused internal tool with one decision-maker, much of that overhead does not change the result.
Nearshore teams offer closer time zones for European hours and often good English, with rates below UK levels. India-based teams offer the lowest rates, and the overlap with the UK is workable: our afternoons and evenings in India line up with your late morning and afternoon.
The honest caveat: a lower rate only saves money if the days are spent well. A cheap team that needs twice the days, or builds something you must rewrite, is not cheap. Judge suppliers by the quality of their questions during scoping, the clarity of their estimate and their willingness to put code in your repository from the first week.
What does a discovery phase cost, and is it worth paying for?
A discovery phase is paid time spent understanding the problem before building anything, and it is usually worth it for any system beyond a simple tool. It shrinks the biggest risk in bespoke software: building the wrong thing well.
The UK government's own Service Manual on discovery puts it plainly: before you commit to building a service, you need to understand the problem, and you should not start building in discovery. It is followed by alpha, beta and live phases. Private-sector projects can borrow that thinking at a much smaller scale.
For a small or mid-sized system, our discovery is short: calls with the people who will use the system, a walk through their spreadsheets and emails, a list of user roles, the systems it must talk to, and a clickable outline of key screens. The output is a written specification with a feature-by-feature estimate you can take to any supplier.
If your needs are already written down clearly, discovery can be brief. If three departments each describe the process differently, it should be longer, because those disagreements are cheaper to settle on paper than in code.
What drives bespoke software development cost up?
Integrations, user roles, data migration and compliance push bespoke software development cost up more than screen count does. A system with twenty simple screens and no integrations can cost less than one with eight screens that must sync with three other systems.
Integrations
Every connection to accounting, CRM, payment, courier or legacy systems means learning its API, mapping data both ways, handling failures and testing edge cases. Poorly documented older systems cost the most.
User roles and permissions
Each role that sees different data or can do different things multiplies the testing. Admin, manager, staff and customer roles are common; field-level permissions add more.
Data migration
Moving years of records from spreadsheets or an old database means cleaning duplicates, fixing formats and agreeing what to leave behind.
Compliance and audit trails
Logging who changed what and when, retention rules, and access reviews add real work, especially with personal or financial data.
Reporting
A few fixed reports are quick. Flexible, filterable reporting with exports is a feature in its own right.
When you want a lower quote, cut from this list first. Launching with one integration and adding the second in phase two often halves the risk of the first release.
How much contingency should a software budget include?
Every software budget should carry contingency, because some requirements only become clear once people use early versions. The right amount depends on how well the work is understood: more for a new process nobody has tried, less for rebuilding a system everyone already uses daily.
We do not tell you a standard percentage, because it would be a guess dressed up as a rule. Instead, we mark each feature in your estimate as well understood, partly understood or unclear. The unclear ones are where contingency belongs, and where a short spike (a day or two of investigation) can turn an unknown into a known before you commit.
Keep contingency as a separate line in your internal budget rather than asking the supplier to hide it inside their price. That way, if the project runs smoothly, the money stays yours, and if it does not, you can see exactly what it was spent on.
The fastest way to use up contingency is changing direction mid-build. Changes are normal; we log each one in writing with its effect on days and cost before doing the work.
Fixed scope or time and materials: which is cheaper?
Fixed-scope contracts give certainty on price for a clearly defined system; time and materials gives flexibility when the details will change. Neither is automatically cheaper. The cheaper one is the one that matches how well you understand what you need.
With a fixed-scope contract, the supplier carries the risk of overruns and prices that risk in. You pay a premium for certainty, and every change becomes a change request. It works well when the specification is detailed and stable, for example replacing an existing system feature for feature.
With time and materials you pay for days actually worked. It suits new processes, products still finding their shape, and projects where you want to reprioritise as you learn. The risk shifts to you, so you need visibility: weekly progress, a running total of days, and a working version you can click through.
A phased approach often suits UK small and mid-sized firms best: a fixed-scope first release built on a clear specification, then later phases priced one at a time once people have used it. That is how we usually structure our quotes. The written quote sets out exactly what is included, and see our terms for the general conditions.
Bespoke software development cost vs SaaS: which costs less over five years?
Per-seat SaaS usually costs less in year one; bespoke software can cost less by year three to five if you have many users, unusual workflows or several subscriptions that one system could replace. The only way to know is to model both for your headcount.
Build the SaaS column first: monthly seat fee multiplied by users, multiplied by sixty months, plus add-ons, integration tools and any price rises you expect. Remember headcount growth; seat fees rise with every hire.
Then the bespoke column: build cost, cloud hosting for sixty months, support and a sensible allowance for new features each year. Hosting for an internal business system is usually modest, and it is paid to the cloud provider in your own account.
Cost is not the only line. SaaS gives you a product team you never have to manage and features you did not have to specify. Bespoke gives you a system that fits your process exactly, data you control, and no vendor deciding to change pricing or retire a feature. If your process is standard, buy. If your process is how you compete, build. Our bespoke software development service page explains what building with us involves.
Bespoke software development cost after launch: what does it take to run?
After launch, bespoke software costs hosting, monitoring, security updates and ongoing changes. Budget for these from the start, because a system nobody maintains becomes a liability.
Hosting is paid directly to your cloud provider. Security updates cover the framework, libraries and operating system; skipping them is how systems end up with known holes. Monitoring means someone notices when a scheduled job fails or an integration stops syncing, ideally before your staff do.
Then there are changes. Every system that people use gets change requests: a new report, an extra field, a tweak to a workflow. Budget some developer time each year for them, because a system frozen at launch slowly drifts away from how the business works.
With us, the first two months after go-live are free support: bug fixes, small adjustments and help as your team settles in. After that, support starts at US$120/mo, and larger features are quoted separately. Our guide to maintenance costs in the UK covers the website side of the same question.
Do technology choices change the cost of bespoke software?
Yes, mostly through long-term costs rather than the build. Mainstream, well-supported technology is cheaper to maintain and easier to hand to another developer later.
We build web-based systems with widely used frameworks and databases, hosted on major cloud platforms in your own account. That means any competent developer can pick up the code after us, and you are not tied to one supplier's private tools. A mobile app, if you need one, is built in Flutter or React Native and costs from US$600; many internal systems do not need one because a responsive web app works on phones.
Be cautious with anything that ties you to an unusual language, a low-code platform you cannot export from, or a supplier's in-house framework. They can be quick to start with, but the cost appears later when you want to change supplier or the platform changes its pricing.
- Web app first; add native mobile apps only when offline use or device features demand it.
- Cloud hosting in your account, in a UK or European region if you prefer.
- Source code in a Git repository you own from week one.
- Documented set-up so another developer could deploy it without us.
UK GDPR and security: how compliance affects the cost
If your software handles personal data, building in data protection from the start costs less than adding it later. The ICO's guidance on data protection by design and by default explains that UK GDPR Article 25 requires controllers to embed appropriate technical and organisational measures and to limit use of personal information to what each purpose needs.
In practice, the build supports your obligations through role-based access, encryption in transit and at rest, audit logs of who viewed or changed records, retention and deletion routines, and collecting only the fields you genuinely need. Each of these is a line in the estimate, not an afterthought.
Some UK buyers also ask about Cyber Essentials. The NCSC describes it as the minimum standard of cyber security recommended by the government, based on five technical controls, and notes that a growing number of organisations require suppliers to be certified. If your contracts need that, raise it before we quote so we can discuss how the build and hosting set-up fit your own certification.
Compliance remains your responsibility as the organisation using the data, confirmed by your own adviser. We build the controls; your lawyer or data protection lead signs off the approach.
How to compare bespoke software development cost across quotes
Compare quotes on the estimate breakdown, not the total. Two quotes can differ because one supplier understood your system better, or because one left things out.
- Does the quote list features and days, or only a single figure?
- Is discovery included, separate, or skipped?
- Which integrations are included, and at what depth?
- How many user roles, and what can each do?
- Is data migration included, and who cleans the data?
- What does support cost after launch, and what does it cover?
- Who owns the code and the cloud account, in writing?
- Will you see working software every week or two?
Ask each supplier the same questions and put answers side by side. If you are weighing a local supplier against a remote one, our offshore vs local developers comparison goes through the trade-offs for UK buyers.
Commissioning bespoke software from India while based in the UK
You deal directly with the three developers building your system, over video calls, WhatsApp and a shared task board. There is no account manager in between, and no office visit, so decisions are captured in writing.
The time difference is four and a half hours in British Summer Time and five and a half in winter. Our working afternoon overlaps your late morning to mid-afternoon, which is when we hold calls and demos. Questions sent in your afternoon are often answered by your next morning.
Quotes are in USD; you can pay from a GBP account through Wise, bank wire or PayPal, with invoices issued from India. Nothing is billed before you approve the written quote. Code is committed to your repository throughout, so you always hold the latest version.
First week
Kick-off call, access to your existing spreadsheets or systems, user roles confirmed, and the first screens sketched for your comments.
Second week
The database and login are set up in your cloud account, and you click through the first working screens on a test link.
Who owns bespoke software once you have paid for it?
You should own the source code, the database, the cloud account and the intellectual property, with that stated in writing. If you do not, you have paid to build something you are only renting.
Check three things in any contract. First, an assignment of intellectual property to you once paid, not a licence to use it. Second, where the code lives: it should be in a repository under your organisation's account. Third, who holds the hosting and domain accounts.
Suppliers sometimes reuse their own components across clients. That is fine if it is disclosed and you receive a licence you can pass on to another developer. We build in your repository and your cloud account from the first week, so there is no handover moment where you depend on our goodwill.
Worked example: estimating bespoke software for a Leicester distributor
This scenario is hypothetical and exists only to show the arithmetic. Say a wholesale distributor in Leicester runs orders, stock and delivery routes across five spreadsheets and a shared inbox. Twelve staff use them daily. It pays for two SaaS tools that each do half the job.
Discovery: a short phase maps the process, confirms four user roles (office, warehouse, drivers, managers) and two integrations (accounting and a courier label service). The specification lists fourteen features, each marked clear or unclear.
First release: orders, stock, delivery lists and a manager dashboard, with the accounting link. That sits above our US$900 starting price because of the integration and four roles. The courier integration moves to phase two, keeping the first release smaller and quicker to test.
Five-year view: the owner compares twelve seats on the two SaaS tools for sixty months against the build, hosting in their own cloud account and support from US$120/mo after the free months. The deciding factor ends up being fit, not only money: the spreadsheets existed because neither tool matched how they pick and deliver.
Warning signs in a bespoke software proposal
Be wary when a proposal is vague about scope, ownership or what happens after launch. These gaps are where bespoke software development cost overruns begin.
- A single total with no feature breakdown.
- No discovery for a system with several departments or integrations.
- Code kept in the supplier's repository until the final payment.
- Hosting set up in the supplier's cloud account.
- No mention of tests, security updates or support after launch.
- A promise that nothing will change during the build.
- Pressure to sign before you have seen a written specification.
Bespoke software development cost: budget checklist
Before you set a budget or approve a quote, make sure each of these has a figure or a clear owner. Missing lines are the usual cause of budgets that double.
- Discovery or specification work.
- Build, broken down by feature with days per feature.
- Each integration listed separately.
- Data migration and clean-up.
- Contingency held in your own budget.
- Cloud hosting, paid in your account.
- Support and security updates per year.
- New features you already know you will want next year.
- Your staff's time for testing and training.