- Commission a build when a valuable process cannot be served economically by configuring existing tools, and scope it from the operational problem rather than a feature list.
- Know what your code contains. In a vendor estimate, Black Duck, which sells code-scanning tools, found open source in 98% of the codebases it audited and licence conflicts in 68% for its 2026 report.
- Software ages after launch. A government review estimated that 28% of systems in central government departments were legacy in 2024, so agree maintenance, backups and code ownership before handover.
Bespoke software development means creating software around a defined organisation, process or product. It makes sense when important requirements cannot be met economically by configuring existing tools, and when the business can support the build and its ongoing operation.
Describe the operational problem before the features
Start with a real sequence of work. A new customer arrives, a team checks information, a task is assigned, a document is prepared and someone approves the result. Record the delays, duplicate entry and decisions that make that sequence difficult. Then identify the smallest improvement worth funding.
A request for “a dashboard with AI” leaves the most important questions unanswered. A request to give staff one view of a customer’s messages, requirements and pending actions is easier to scope and test. Agree which users need access and the evidence that will show whether the new system helps.
What can a bespoke system include?
Common projects include customer portals, internal operations tools, custom CRMs, reporting applications and integrations between existing products. Some are complete platforms; others are a small layer connecting systems that already work well.
For example, Walthams combines public website development with staff and customer access. Socialroom brings brand context, content, media and approval stages into a dedicated workspace. The relevant lesson is to make the product follow the work, with a clear boundary around the first release.
What drives the price?
| Cost driver | Question to settle |
|---|---|
| Users and permissions | Who can view, change, approve or export each type of record? |
| Data migration | How complete, consistent and accessible is the existing information? |
| Integrations | Are documented APIs and suitable account permissions available? |
| Business rules | How many exceptions need specific handling? |
| Reliability and support | What recovery, monitoring and response arrangements are needed? |
A meaningful estimate follows discovery. Compare proposals against the same scope, including hosting, third-party subscriptions, maintenance and expected changes. A lower build quote can leave significant costs outside the agreement.
Deliver in stages that can be reviewed
Discovery should produce an agreed scope, user journeys, data model and acceptance criteria. Design should make important screens and interactions reviewable. Development should create working increments, followed by tests of normal use, exceptions and permissions.
Before launch, reconcile migrated records, check integrations and test how the system recovers from failure. Train the people who will use and administer it. A phased launch can reduce disruption where a team needs time to compare the new process with the old one.
Timescales depend on scope and dependencies. Content, access to third-party accounts, data quality and the speed of review can matter as much as coding. Ask for milestones and the assumptions behind them rather than an unsupported universal delivery promise.
Put data protection in the brief, not the handover
A bespoke solution is the one moment you get to decide how personal data moves through a system before it exists. Under UK GDPR that's your job, not the developer's. Article 25 puts data protection by design on the controller, the business whose data it is, and the ICO says you should include data protection by design considerations in any decisions you make about the products and services you use (ICO: data protection by design and default). The same guidance says you must only use processors that give sufficient guarantees.
In practice that turns into four lines in the specification, each cheap to build now and costly to bolt on later. Which roles can see which fields. How long each kind of record is kept, and what deletes it. How a person's data is found and exported when they ask for it. And where the system logs who changed what. Ask any bespoke software development company you're comparing to show where each of those sits in its proposal. A supplier that treats them as extras to price later hasn't built many systems that hold customer records.
Agree ownership before the handover
The agreement should explain ownership and access to source code, designs, data, infrastructure and documentation. Third-party components can have their own licences. Specify how records can be exported, who controls production accounts and how another team could maintain the application.
Maintenance covers more than fixing visible errors. Dependencies, provider APIs and business needs change. Agree monitoring, backups, updates and a process for requesting improvements. Our platform and hosting page explains the difference between self-hosted and managed delivery.
Still deciding whether to build? Use the bespoke versus off-the-shelf comparison and the custom software FAQs before commissioning a detailed brief.
Sources
Every figure in this article links back to the source below it was checked against.
Written for Orwell Lab’s practical guide collection. Statistics sourced and checked on 30 September 2026.
Discuss your own requirements ↗