BPP (via Build Circle)

BPP is a UK higher education and professional training provider. Following its acquisition of Buttercups Training, BPP needed a unified learner dashboard for the apprenticeship side of the business. Learners needed one place to see their progress, and supervisors needed one place to see how the people they look after were getting on. The driver was an upcoming Ofsted inspection. The existing experience was spread across Campus (the internal Buttercups platform), Beehive (the legacy VLE), and OneFile (an external e-portfolio SaaS), and tutors were flipping between systems to answer basic questions about progress. The project was called Beacon internally.

I joined through Build Circle in mid-December 2025 as Solutions Architect, on a roughly three-and-a-half month engagement. The wider team was around nine developers split across three workstreams: the learner dashboard itself, the progress engine that fed it, and the BAU work on Campus and the Buttercups platform. About two-thirds of the team were junior, including bootcamp graduates and developers new to the languages they were working in. A good portion of my time went into establishing patterns the team could carry forward without me.

The architecture landed on three new repositories: Learner Dashboard, Progress Engine, and a OneFile integration. The progress engine and OneFile repos were pulled into the dashboard repository as sub-repositories, so the whole system could be brought up locally as one piece. The dashboard itself was a Vue.js front end backed by a C# backend-for-frontend. The progress engine provided a consolidated view derived from Campus (PostgreSQL), Beehive (via Campus), and OneFile (overnight SFTP CSV exports landing in Azure Blob). Auth0 handled authentication for the dashboard, and SAML single sign-on linked through to Beehive for deep linking into specific course pages.

The architectural decision I'm most pleased with was bringing in .NET Aspire. The proposed shape was a small set of microservices with two Azure Functions, a SQL database, Blob storage, and Redis. That kind of topology is notoriously awkward to run end-to-end on a developer's laptop. I'd been using Aspire on my own infrastructure for SoftWeb and recommended it as a way of restoring an F5 development experience: hit run, get the whole ecosystem (services, dependencies, databases, storage, cache) wired up and ready. That is exactly what we got. I tend to describe Aspire to clients as a compile-time, type-safe alternative to Docker Compose, and this engagement was the first time I'd taken it from a promising tool to a production team workflow. One sharp edge worth flagging: when sub-repositories are pulled into Aspire as references, the parent repo's commit pointers can drift if developers commit references to short-lived feature branches. We worked around it by being disciplined about pointing sub-repos at long-lived branches, but it is a real co-ordination cost in multi-repo Aspire setups.

The other defining feature of the engagement was Claude Code use throughout discovery and delivery. The first two to three weeks were pure discovery. The project was greenfield, the team was junior, and three unfamiliar third-party platforms (Campus, Beehive, OneFile) all needed to be understood before anyone could write a sensible line of code. I used Claude Code to run parallel research agents across the platforms, reverse-engineer the relevant Campus APIs, derive a component library from the design screenshots presented at the kickoff, and produce data mappings I could then verify with the senior developer from Buttercups. By the end of week one I had a runnable Vue.js front end and matching C# back end in front of the team, initially fed by mock data and then wired through to real services. That proof of concept was not throwaway. The team built directly on it for the next three months and it became the MVP that shipped at the end of the engagement.

There were challenges along the way. The original plan for OneFile was to pick up CSV exports that an existing low-code data pipeline (maintained elsewhere in the organisation) was landing in Azure Blob. About two weeks before the contract end it became clear that pipeline was a labelled proof of concept, sat in a different Azure boundary, and was not viable for production. I pivoted the OneFile integration to read directly from the source SFTP. Late, but unavoidable. A senior teammate from Buttercups left shortly after I started, and a junior teammate went off sick for an extended period mid-project, leaving a chain of unmerged pull requests. Once it was clear he would not return in time, I consolidated and reconciled them against main. BPP also adopted Claude Code internally during the engagement, so a portion of my time went into mentoring the team on AI-augmented development practices alongside the language and architecture coaching the work needed anyway.

The MVP shipped at the end of the engagement, roughly two weeks after the Ofsted inspection itself. The build state at the time of the inspection was enough for BPP to evidence to inspectors that the apprenticeship visibility gap was being actively addressed, and the full MVP completed shortly afterwards: a Vue.js learner dashboard, a C#/.NET 10 backend-for-frontend, a progress engine consolidating data from Campus, Beehive and OneFile, and a fully Aspire-orchestrated local development experience. I left behind component patterns, integration patterns, and an Aspire-based development workflow that the in-house team could continue to build on without me.