Learning Infrastructure, Scope & Scale

My Role

I owned the problem definition, build-vs-buy analysis, vendor evaluation, pilot design, recommendation, commercial negotiation and phased implementation.

As we were a small team, we took most decisions together. When someone felt strongly about a feature, they had to test their hypothesis to validate or disprove it.

Training program

Q-Bot installs underfloor insulation in confined spaces, which means dealing with safety and compliance requirements.

Training already existed, but the infrastructure didn't. Courses lived in PDFs and guides; completion was tracked in spreadsheets; refresher and competency records were maintained manually by depot managers and the training team.

The company was also scaling through partners. Every new partner multiplied a process that was already heavily administrative.

The trajectory was problematic.

The brief was smaller than the problem

The initial brief was an installer companion app. Through cross-team discovery, we established that the underlying need was broader.

The same infrastructure required to support:

• Internal delivery teams and existing partners
• Prospective partners during onboarding
• Company-wide HR and compliance training
• CPD-accredited content for customers and specifiers

The fourth audience changed the business case. The first three primarily reduced operational cost; CPD could influence revenue by helping housing associations, retrofit coordinators, architects, managing agents and contractors understand a new retrofit technology.

The team estimated nearly £400k/year in operational savings and £1.34m/year in potential revenue influence.

That opportunity shaped the platform decision, and later exposed the biggest weakness in our thinking.

Building vs buying

With our engineering team focused on other projects, we explored whether to build the LMS ourselves or buy from a third party. My research quickly showed that the core feature set was largely commoditised.

I defined 12 initial requirements including multi-device support, SSO and integration with our existing systems. Several off-the-shelf platforms met most of our requirements, so we closed build-vs-buy quickly.

Evaluate the architecture

Vendor feature grids looked similar. The differentiators emerged in technical discussions.

I added requirements around APIs, authentication, webhooks, CORS and integration with our existing tools. This eliminated options that looked attractive on paper but would create significant engineering or support overhead.

12 platforms reviewed → 7 benchmarked → 3 piloted

I set the down-select criteria in advance: product fit, integration capability, low internal engineering dependency and total cost.

Make the pilot answer specific questions

Rather than asking which platform people liked most, I separated the pilot into four questions:

• Could it deliver our essential training at a reasonable cost?
• How was the administrator experience?
• How was the learner experience?
• Could the backend, API and security capabilities support our product direction?

Installers tested the learner experience. Platform administrators tested authoring and user management. Engineering assessed API, authentication, webhooks and GDPR.

The result wasn't simply a winner. It gave us a clearer specification for the dashboard we actually needed.

Choosing for the strategy, not the cheapest scenario

I recommended the most expensive option.

Under a 100-user scenario it cost almost twice the cheapest option. But its unlimited-user pricing made it significantly more attractive if the projected external growth materialised.

The strategic choice was straightforward: if we believed the £1.34m revenue opportunity, choosing a platform optimised only for the low-user scenario would undermine the strategy.

I negotiated a one-year contract with 10% discount rather than committing to a two-year deal. That preserved the option to reassess once we had evidence that the commercial opportunity was real. This became one of the most valuable decisions in the project.

We also had to accept known limitations. The platform lacked some desired requirements, but the pilot made these gaps explicit. That gave us the evidence to decide which trade-offs we were willing to accept.

Delivering the compliance mandate

The platform went live in August 2023, with internal and external course rollout beginning in October.

What we achieved:

• 100% compliance on mandatory training
• 50+ internal users onboarded at launch
• 14 mandatory courses moved from PDFs and manual sign-off into learning paths
• Automated certification, refresher and expiry tracking
• Compliance evidence became queryable rather than reconstructed from spreadsheets

What we did not achieve:

• The projected efficiency gain was overstated. Tracking effort fell, but user setup and administration absorbed a significant part of the saving.
• The revenue opportunity didn't materialise. The CPD portal launched, but the commercial team didn't commit the resources needed to use it meaningfully.

The subscription was ended in November 2024 following a change in company direction. The one-year contract meant we could exit without being tied into a longer commitment.

Scope is a product decision

The projected revenue opportunity was not realised, not because the product couldn't support it, but because we didn't have the organisational capacity to make it happen.

I scoped to the size of the opportunity rather than the size of the committed resource.

What I'd do differently:

• Prove the operating model with one audience, then expand when there is a named owner and capacity to support it.
• Treat ownership and available capacity as seriously as platform capability or cost.
• Model the cost of change. Our business cases counted the work we would remove, but not enough of the administration we would add.

The flexibility to reverse the decision after one year was ultimately more valuable than any feature on the comparison grid.