Most initial platform projects fail before the technical phase. They fail because they have aggregated requests from four different services, produced a forty-page requirements document, and discovered after six months that no one could define what success looked like.
Five questions avoid most of this waste. They are addressed in two workshops.
Who is the primary user?
Not 'the users': an user. The one whose daily life changes the most if the tool exists, and who will open it every day. The other professionals will come after.
An application designed for three user groups simultaneously ends up being too generic for each. Prioritising a primary user does not exclude anyone definitively: it simply prioritizes the work.
What problem recurs often enough to warrant attention?
A software is profitable when it addresses a frequent issue. A situation that occurs three times a year does not justify an interface; it justifies a written procedure.
The right unit of measurement is the number of occurrences per week, and the time consumed each time. This figure, even approximate, immediately indicates whether the project is worth existing.
What data is critical?
Every platform relies on a central piece of data: the dossier, the client, the operation, the contract. Identifying which one and its source of truth prevents the most common scenario: two systems holding the same information but never agreeing.
This is also the time to identify sensitive data. Roles and permissions are designed at the beginning, when the model is simple, never after the fact.
Who is responsible for what?
A product without a dedicated owner drifts. Three responsibilities must be named from the start, and they don't necessarily need to be carried by the same person.
- Who defines the scope and says no to additions?
- Who responds to users when something isn't working?
- Who decides on the evolutions once the V1 is live?
How much will it cost to maintain?
Development is a one-time investment; operation is a permanent expense. Hosting, backups, security updates, support, and regulatory changes: this line must be in the budget before launch, not after the first incident.
A useful order of magnitude: allocate between 15% and 25% of the initial construction cost annually to maintain an operational tool. Below this, debt accumulates.
What a reasonable V1 contains
A first successful version is not a poor version: it is a complete on a journey. It’s better to have an impeccable journey than six half-finished ones.
| In the V1 | Later |
|---|---|
| The priority user journey, from start to finish | The journeys of secondary professionals |
| Authentication, roles, and logging | Fine-grained permission personalization |
| The two or three essential integrations | The rest of the information system |
| The usage indicators | Advanced dashboards |
| A data export | Custom reports |
To keep in mind
- A primary user, a primary path: the rest will wait.
- Count the weekly occurrences: the frequency justifies the project, not the desire.
- Name the key data and its source of truth during the scoping.
- Three responsibilities to assign before starting: arbitration, support, evolution.
- Budget 15 to 25 percent of the initial cost annually for operation.