Before you rebuild: how an independent review gave Edwin Group a safer path for Llama ID

Customer Background

Edwin Group is a UK education services organisation. Its platforms support safer recruitment, compliance and identity verification for schools, teachers and education professionals across the country.

Llama ID, launched as part of the group’s growth strategy, is a digital identity and verification platform. It handles sensitive personal information about people working with children, in a heavily regulated sector. As adoption grew, it stopped being a new product and became something the business depended on.

The Challenge

Llama ID had been built by an external supplier and was performing well. Usage was growing. But an internal review had raised concerns about code quality and some infrastructure decisions, and leadership needed three questions answered before investing further:

• Is sensitive data being handled properly?
• Will the platform cope with continued growth?
• Can the architecture be maintained for the long term?

An internal view wasn’t enough to take to the board. Edwin Group didn’t want to guess, and it didn’t want to commit to an expensive rebuild unless the evidence said it had to.

Our Approach

We started with the business, not the code. In the first phase we sat down with Edwin Group’s leadership and technical team to understand how Llama ID earns money and supports operations, what data it holds and for how long, the growth plan for the next 12 to 24 months, and how much risk and spend the business could tolerate. That kept the review anchored to decisions Edwin Group actually had to make, not to a generic best-practice checklist.

We then reviewed the platform end to end: hosting and resilience, security controls and data handling, deployment and release, code maintainability, architecture and dependency management. We looked at how those parts affected each other, because most real risk sits in the joins.

Being independent mattered. In a regulated sector, the board needed an assessment from someone with no stake in the original build and nothing to sell on the back of the answer.

What we found and recommended

We turned the findings into a staged roadmap:

• Now: actions to reduce immediate security risk.
• Next: structural fixes to releases, access and hosting.
• Later: options for modernising the architecture, component by component.

Each item was ranked by business impact, effort and the risk it removed. We were clear that not everything needed fixing, and that the platform did not need replacing.

Delivery: what Edwin Group did next

Edwin Group acted on the roadmap straight away:

• hardened security and tightened access controls and governance
• introduced a structured CI/CD pipeline to reduce release risk
• started upgrading dependencies with known vulnerabilities
• agreed a phased move to cloud hosting
• chose to replace higher-risk components one at a time while the platform stayed live

The Outcome

• A rebuild avoided. Edwin Group protected its existing investment and replaced a large, disruptive project with a phased plan it controls.
• Lower security exposure. The most serious data-handling risks were addressed first.
• Safer releases. CI/CD reduced the chance of a release breaking a live service.
• Board-ready evidence. Leadership has an independent, documented view of platform health to support governance and investment decisions.
• Spend pointed at the right things. Technology budget now goes to the improvements that remove the most risk.

Frequently asked questions