How an EdTech startup built adaptive learning on Vertex AI

The fixed path that loses learners

An EdTech product lives or dies on whether learners keep going, and a single fixed path works against that for almost everyone. Set the same sequence for every learner and you pitch it wrong for most of them. The strong ones are bored by work they have already mastered. The ones who are behind hit a wall, fail a few activities in a row, and quietly leave. Either way the product is teaching to an average learner who does not exist.

The founders we work with feel this in the numbers. Completion drops at predictable points in the content, support tickets cluster around the same hard topics, and a slice of new sign-ups never make it past the first session. The instinct is to keep adding content. The actual problem is sequencing. The right next activity for a given learner already exists in the library. The product just has no way to choose it for them, one learner at a time, thousands of times a day.

Hand-tuning that is impossible at any real scale, and a rules engine of “if they pass two, show the next” is too blunt. It cannot tell a lucky guess from genuine mastery, cannot read that a learner is slowing down, and cannot adapt to how this learner specifically is moving through the material. This is a pacing problem with a lot of signal in it, which is what machine learning in education is actually good at. It is also why difficulty, not content volume, is where an adaptive learning engine earns its place.

Why Vertex AI, and what sits around the model

The aim is an adaptive recommendation model that reads each learner’s progress and returns the next activity at the right difficulty, served live inside the product. We headline these builds on Vertex AI, Google Cloud’s machine learning platform, for three practical reasons that matter to a startup team.

First, managed training. Vertex AI runs the training pipelines and keeps versioned models in a registry, so retraining as new learner data arrives is a scheduled job rather than a hand-run script on someone’s laptop. Second, managed serving. The model is exposed as an online prediction endpoint with the latency and autoscaling a live product needs, so a recommendation comes back inside a lesson load, not seconds later. Third, the supporting pieces, including a feature store for the learner and content signals the model reads, are part of the platform rather than infrastructure the team has to build and operate themselves.

That last point is the real argument against rolling your own. A small EdTech team can stand up training, a model registry, a feature store and a serving endpoint on bare compute, but then it owns all of it, including the on-call. Vertex AI lets the team spend its engineering on the model and the product, not on the plumbing under them. Around the model, learner and event data lives in PostgreSQL as the product’s source of truth, and the wider application runs on Google Cloud, so the recommendation engine sits inside one environment rather than reaching across clouds for every prediction.

Building it, and where it got hard

The model architecture was rarely the hard part. The friction was in the gap between a model that scores well offline and one that actually helps a learner, and one problem stands in for the rest. The new learner.

A recommendation model is only as good as the history it has, and a brand-new learner has none. This is the cold-start problem, and early in testing it showed up exactly where it hurts most. The opening session. With nothing to read, the model’s first few recommendations were close to guesses, which meant a fresh sign-up could be handed work that was far too hard or insultingly easy before they had done anything. That is the worst possible moment to misjudge a learner, because they have not yet decided to stay.

There was a related trap hiding underneath it. A model tuned to keep learners engaged learns that easy work keeps them clicking, so left alone it parks a learner in their comfort zone and the learning stalls. Optimising for time-on-app would have made the dashboards look good and taught nobody anything.

The fix had three parts. For new learners we used sensible content-based defaults, a short placement signal and the difficulty structure of the content, so the first session was pitched roughly right while the model gathered real signal. We built deliberate exploration into the recommendation policy, so it periodically tests slightly harder material rather than always playing safe. And we changed what we evaluated on. The model is measured on learning gain through assessment improvement, not time-on-app alone, so a recommendation that boosts minutes without lifting mastery counts as a miss. None of that is exotic machine learning. All of it is the difference between a model that demos well and one a learner stays with.

Two constraints shaped the rest. Because under-18 learners were in scope, children’s data was a design constraint from the first sprint, handled under the Privacy Act 1988 with parental and school consent and clear retention rules, not bolted on at the end. And because recommendations are automated, we kept them transparent and the data they use scoped to what the feature needs.

What changed

In a representative build, pitching the next activity at the right difficulty lifted lesson completion noticeably against the old single fixed path, mostly because fewer learners hit a wall of too-hard work and gave up. The content-based defaults shortened the rough opening stretch for brand-new learners, so a first session felt useful rather than mistimed. And because the model was evaluated on assessment improvement rather than time-on-app, the gains showed up as learning, not just longer sessions.

These figures are illustrative. They describe the pattern we see rather than a published result for a named product. The shape is the point. The same content library, sequenced per learner instead of one path for all, meets each learner near the edge of what they can do, which is where both engagement and learning actually come from. That is what an adaptive learning engine adds that more content alone never will.

Where this fits

An adaptive recommendation engine is one application of our Software Development service, built on Vertex AI, for an EdTech product. It is a contained, high-return place to start, because the content and the learner data already exist and the value comes from sequencing them well and serving that live inside the product. If your completion drops at the same points and new learners churn in the first session, the place to start is to map your content difficulty and learner signals and decide the one recommendation that would change a learner’s path.