What should go in version 1 of a custom platform?

The short answer

Version 1 is the smallest thing that lets you learn whether the idea works. That means one workflow, done end to end, for the roles who touch it. Everything else waits, and “waits” has to be written down.

Why owners ask this

Because the usual story is that a 30-day plan quietly becomes a 90-day plan, one reasonable request at a time. Nobody agreed to a delay. Each addition just seemed small. A written scope is what makes the additions visible while they are still cheap to say no to.

What good looks like: the seven parts of a version-1 scope

1. The one workflow. One sentence. “A patient books a slot or joins the queue, and reception and the doctor see the same queue.”
2. The roles. Who uses it, and what each role must be unable to do.
3. The in-scope list. Features, each small enough to test.
4. The out-of-scope list. Named items, with a reason each. This is the page people argue about, which is why it exists.
5. The change process. Anything not on the list is a change request: what changes, what it costs, what moves.
6. The acceptance test. The end-to-end journeys that must work before you call it done.
7. The time box. A date, and what happens if a dependency outside the vendor’s control slips.

A useful test for the out-of-scope list: if a stakeholder reads it and nothing on it makes them wince, it’s too short.

How we did it

For the clinic-queue platform, the first release was scoped to 30 days by a written feature map. Payments and WhatsApp were out, because neither fits a 30-day window. Anything new was treated as a change request.

The scope did change once, and the way it changed is the useful part. We had assumed the operations team would onboard clinics and doctors directly in the database console. That stopped being realistic, so an admin panel was added. It was handled as a change to the original scope, not slipped in. In the end the most useful page in the build was the list of what we wouldn’t build.

Some things were a floor, not a feature. For an app in a health category, the app stores require that someone who creates an account can start deleting it from inside the app. Apple’s guideline says apps that support account creation “must also let people initiate deletion of their account within the app,” and that offering only temporary deactivation isn’t enough (Apple, App Review Guideline 5.1.1(v)). So consent capture and in-app account deletion went into version 1. Cutting them would have only delayed the launch.

That is the pattern to look for: separate what you can defer from what the platform, a store or a law won’t let you defer.

Where this doesn’t apply

Questions to ask any vendor, including us

1. Can I see the out-of-scope list before we start, and why each item is on it?
2. What happens when I ask for something that isn’t on the list?
3. Which items in my scope can’t be deferred, and why?
4. What’s the acceptance test, in the form of journeys, not features?
5. What does a slipped dependency do to the date, and who carries it?

Next: Should we build custom software or buy SaaS? and how to test before real users arrive. Part of the guide Buying custom software and hiring a tech vendor.