23 October 2026

Cut the MVP down to one complete cycle

We shipped Entra’s MVP in a week and placed 90+ trainees with it. The trick wasn’t speed. It was deciding what not to build, and writing down why.

The Entra dashboard a BDM sees: total, pending, in-progress and successful requests, with notifications

Everyone says “start small”. Fewer people say what small actually means.

On Entra, AmaliTech’s internal staffing platform, small meant one complete cycle: set up a project, let people apply, and select who gets placed. That’s it. Nothing else made it into the first release.

The wish list was already long

Before we had written a line of code, the list included notifications, CV upload, single sign-on and a mobile layout. All reasonable. All things people would eventually want. And every one of them would have pushed the first release back.

Trainees needed placing on projects, and they needed it soon. So I asked one question of every item on the list: does the cycle break without it? If the answer was no, it moved out.

Deferring is not the same as dropping

This is the part I’d tell any product owner to copy. Write down why each thing was deferred. Not in your head, in the backlog, right next to the item.

Two things happen when you do this. Stakeholders stop reading a cut as a “no”, because they can see it’s a “not yet” with a reason behind it. And when the pilot comes back, you already know which decisions to revisit and why you made them in the first place.

Real use beats a long list of guesses

The MVP shipped in a week, and we used it to place 90+ trainees. Then the pilot review told us exactly what to fix first, and it wasn’t always what we would have guessed. The rebuild that followed was shaped by how people actually used the product, not by the wish list we started with.

That’s the real payoff of a small first release. Not the speed itself, but how quickly you stop guessing.

Entra roadmap from the first sprint to the v1.0 release, with the pilot in between
From the first sprint to an organisation-wide v1.0, with the pilot shaping what came next.

Scope is a product decision

Cutting scope is often treated as a delivery problem, something you do when the timeline slips. I think it’s the first product decision you make, because it says what the product is for.

Entra’s first version said one thing clearly: we exist to get people placed. Every conversation after that was easier, because we had agreed on that before we argued about anything else.

What I’d tell myself at the start

  • Define the smallest complete cycle, not the smallest list of features.
  • Give every deferral a written reason.
  • Get it in front of real users as early as you can, then let the pilot set the priorities.
  • Protect the cycle. If a “small addition” puts it at risk, it waits.

Five months later, Entra went live to the whole organisation. It started with one cycle that worked.