Custom Software Development, Secure by Design and Built Around How You Work

Custom software development for regulated organisations whose off-the-shelf tools and legacy systems no longer fit how they work: portals, workflows and integrations built in agile sprints, secured to NCSC and OWASP guidance, with code you own.

PublishedFriday 29 May 2026 UpdatedSunday 18 October 2026
Custom Software

A new service needs a customer portal, the package vendor quotes a change request measured in quarters, and the team behind it still works from a shared spreadsheet. Thornacre’s custom software development builds the products, portals, workflow tools and integrations a regulated organisation needs, secure by design and shaped around how your people work.

ServiceCustom software development
Who it is forCTOs, IT Directors, Heads of Data, CISOs, DPOs and COOs in any regulated organisation whose tools no longer fit how it works
The problem it solvesPackages that do not fit, processes run on spreadsheets, and systems that cannot share data or produce the evidence regulators ask for
What we deliverNew products and services, staff and customer portals, workflow and case management tools, integrations and APIs, legacy modernisation, training and support
How we workDiscovery then agile delivery as the GDS Service Manual describes, with secure development to NCSC guidance and OWASP ASVS
Regulations and standardsUK GDPR data protection by design, NCSC secure development guidance, OWASP ASVS, NCSC Cloud Security Principles, WCAG 2.2 AA

What problem does custom software development solve?

Custom software development closes the gap between how your organisation works and what its tools allow. It builds what packages cannot: a new service, a portal, a case workflow or the integration between them.

The trigger takes many forms. A new service needs a customer portal no package offers. A regulated process runs on spreadsheets nobody can trace. A legacy system only exports overnight, and its vendor is winding down support. Each persona feels a different part of it:

  • The CTO or IT Director sees workarounds and integration work consume the roadmap.
  • The Head of Data cannot get one current record out of five tools.
  • The CISO carries unmanaged spreadsheets and a platform that will soon stop receiving security patches.
  • The Compliance Lead or DPO gathers evidence by hand when a regulator asks.
  • The COO watches staff rekey the same record into three systems.

The exposure is real. The Cyber Security Breaches Survey 2025 found that 74% of large UK businesses identified a breach or attack in the previous 12 months. Ungoverned tools and unsupported platforms widen that exposure.

None of this is your team’s fault. Packaged products assume a standard process, and regulated organisations rarely have one. Services and channels change faster than the systems built for them, so each workaround adds debt.

How does Thornacre deliver custom software development?

Thornacre delivers custom software development in short, visible phases, with working software at the end of every sprint. The phases follow agile delivery as the GDS Service Manual describes, starting with discovery. The same phases fit a new product, a portal, an internal tool or a legacy replacement.

The diagram shows the path, with the fork where existing systems stay or retire.

Custom software development path: discovery, prototype, sprints, connect existing systems or migrate off one, test, hand over
  1. Run discovery workshops. Map user needs with operations, compliance and IT, using journey mapping, card sorting and personas. Outcome: a specification and a prioritised backlog.
  2. Prototype before code. Produce wireframes and clickable prototypes, with accessibility designed in. Outcome: problems found while they are still quick to fix.
  3. Build in short sprints. End each sprint with working software your team reviews and tests before the next is planned. Outcome: visible progress at every sprint review.
  4. Connect or migrate. Where existing systems stay, connect the new software to them, your CRM and third-party services through documented APIs, as in our CRM and ERP integration work. Where a spreadsheet or legacy system is retiring, migrate its data clean and structured. Outcome: one source of truth.
  5. Test continuously. Run functional, integration, load, cross-browser and accessibility tests in every sprint, then independent penetration testing that follows the NCSC penetration testing guidance. Outcome: issues caught early.
  6. Train and hand over. Provide role-specific materials, a practice environment and recorded guides. Outcome: your team runs the system confidently.

For legacy modernisation, the strangler pattern is an approach where new services gradually take over functions from a legacy system until it can be retired. Every step is a working release.

What do you get from custom software development with Thornacre?

You get software you own, the documentation to run it and support after launch. Thornacre builds on open-source foundations wherever possible, so your data, content and codebase stay yours if you change provider or bring the work in-house.

  • The codebase and data: full ownership, with no lock-in.
  • Secure hosting: designed to the NCSC Cloud Security Principles, with data encrypted in transit and at rest.
  • Accessible interfaces: every build meets WCAG 2.2 Level AA as a minimum.
  • Documentation and training: architecture records, API documentation, role-specific guides and videos.
  • Ongoing support: monitoring, patching and new features after launch.

Which regulations does custom software development help you meet?

Custom software development helps you meet rules that ask for evidence of control over systems, data and suppliers. The cross-sector standards apply to every build:

The Information Commissioner’s Office (ICO) states the principle plainly:

“The UK GDPR requires you to embed data protection practices into every aspect of your use of personal information.” (ICO)

Each sector adds its own rules, one example each:

SectorRegulation or frameworkWhat it requiresHow the service addresses it
Banking and paymentsFCA operational resilience rulesOperate important business services within impact tolerancesDocumented architecture, tested recovery and code you can move
InsurancePRA SS2/21Business continuity and exit plans for outsourcingExit-ready code ownership and handover documents
Private healthcareData Security and Protection ToolkitAssurance of good data security for organisations with access to NHS patient dataAccess control, encryption and logging designed in and documented
Life sciences and pharmaMHRA GxP data integrity guidanceData integrity across the lifecycle of GxP recordsAudit trails on every record change
Public sectorPublic Sector Bodies Accessibility Regulations 2018Accessible websites and apps, with an accessibility statementWCAG 2.2 AA builds and evidence for the statement

How do you choose between custom software and a package?

Buy a package for commodity functions and build custom software where your services, processes or evidence needs are distinctive. Compare the options on what matters to a CTO and a risk owner:

OptionFit to your servicesMaking later changesOngoing effortExit and ownership
Off-the-shelf packageStandard processes onlyWait for the vendor roadmapUpgrades on the vendor’s scheduleVendor controls roadmap
Configure existing platformLimited by vendor modelVendor change requestsChange requests negotiated with the vendorVendor controls roadmap
Custom softwareBuilt to your servicesYour own backlogYour support, patching and hostingYou own the code
Replace a legacy system in one goHigh, once completeFrozen until migration endsHighest: two systems in dual runningDepends on new vendor

Use these rules:

  • If the function is the same across organisations, such as payroll or ledger, buy it.
  • If a package needs heavy customisation to model your process, build it instead.
  • If a spreadsheet runs a regulated process, replace it with a workflow tool that keeps an audit trail.
  • If a legacy vendor is ending support, build the new services first, then migrate data in stages.

The deciding question is not build or buy. It is which option lets you prove you can keep a critical service running, and move it, if a supplier fails.

When is custom software development not the right choice?

Custom software development is the wrong choice for commodity functions and for any organisation that cannot sustain ownership after launch. Plan for support, patching and change every year, and for a product owner on your side who can make decisions each sprint.

A common objection is: “We should just replace the legacy system with a package.” Replacing a core system in one go means migrating every live record and regression testing every process at once, which few organisations can absorb alongside business as usual. Building in steps reduces that risk.

Internal politics matter too: procurement wants fewer suppliers, the business wants speed and compliance wants evidence first. A working release at the end of each sprint gives each of them something to sign off. Waiting is not neutral: every year on spreadsheets and unsupported systems adds rework and security exposure.

Frequently Asked Questions

What kinds of software can you build?

Thornacre builds new products and services, staff and customer portals, workflow and case management tools, internal applications that replace spreadsheets, integrations and APIs, and staged legacy modernisation. Each build follows the same discovery, sprint and testing approach, with security designed in from the first sprint.

What does discovery produce before we commit to a build?

Discovery produces a specification, a prioritised backlog and a tested view of how the new software will share data with your existing systems. It follows the GDS discovery phase approach: understand users and constraints before choosing a solution. Discovery can also conclude that a package fits better, which is a valid outcome.

Will we be locked in to Thornacre?

You will not be locked in to Thornacre. You own your data, content and codebase, and documentation with a structured handover lets another supplier or your own team take over. That ownership also makes the exit plans that regulators expect for outsourced services workable.

How do you secure custom software?

Custom software is secured by following NCSC secure development guidance, verifying against OWASP ASVS and running independent penetration testing before launch. The Cyber Security Breaches Survey 2025 found that only 45% of large businesses review risks from immediate suppliers; Thornacre documents its controls so your CISO can. See our cyber security service.

How do we start a custom software project?

Start by listing the three processes your current tools block today, and what each one needs. Thornacre then runs discovery workshops with your operations, compliance and IT leads to agree which to tackle first. If data must move off an old system, see our data migrations service.


Email your list of blocked processes to hello@thornacre.com and we will run a workshop with your IT, operations and compliance leads to decide which to build, buy or migrate. See also our accessibility service.

This page is general guidance only; consult your legal or compliance teams for your specific requirements.