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.
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.
| Service | Custom software development |
|---|---|
| Who it is for | CTOs, IT Directors, Heads of Data, CISOs, DPOs and COOs in any regulated organisation whose tools no longer fit how it works |
| The problem it solves | Packages that do not fit, processes run on spreadsheets, and systems that cannot share data or produce the evidence regulators ask for |
| What we deliver | New products and services, staff and customer portals, workflow and case management tools, integrations and APIs, legacy modernisation, training and support |
| How we work | Discovery then agile delivery as the GDS Service Manual describes, with secure development to NCSC guidance and OWASP ASVS |
| Regulations and standards | UK 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.

- 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.
- Prototype before code. Produce wireframes and clickable prototypes, with accessibility designed in. Outcome: problems found while they are still quick to fix.
- 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.
- 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.
- 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.
- 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:
- UK GDPR data protection by design: access controls and data minimisation are designed in discovery.
- The NCSC secure development and deployment guidance and the OWASP Application Security Verification Standard: the build follows the first and is verified against the second.
- WCAG 2.2: AA as a minimum, tested before launch.
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:
| Sector | Regulation or framework | What it requires | How the service addresses it |
|---|---|---|---|
| Banking and payments | FCA operational resilience rules | Operate important business services within impact tolerances | Documented architecture, tested recovery and code you can move |
| Insurance | PRA SS2/21 | Business continuity and exit plans for outsourcing | Exit-ready code ownership and handover documents |
| Private healthcare | Data Security and Protection Toolkit | Assurance of good data security for organisations with access to NHS patient data | Access control, encryption and logging designed in and documented |
| Life sciences and pharma | MHRA GxP data integrity guidance | Data integrity across the lifecycle of GxP records | Audit trails on every record change |
| Public sector | Public Sector Bodies Accessibility Regulations 2018 | Accessible websites and apps, with an accessibility statement | WCAG 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:
| Option | Fit to your services | Making later changes | Ongoing effort | Exit and ownership |
|---|---|---|---|---|
| Off-the-shelf package | Standard processes only | Wait for the vendor roadmap | Upgrades on the vendor’s schedule | Vendor controls roadmap |
| Configure existing platform | Limited by vendor model | Vendor change requests | Change requests negotiated with the vendor | Vendor controls roadmap |
| Custom software | Built to your services | Your own backlog | Your support, patching and hosting | You own the code |
| Replace a legacy system in one go | High, once complete | Frozen until migration ends | Highest: two systems in dual running | Depends 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.