Insights · Engineering
Why open standards still win: SCORM, the cloud, and systems clients can actually own
The short version
There is a quiet decision buried in every software project that decides, years later, whether the client is free or trapped: the choice between a proprietary format that only your system understands, and an open standard that any system can. It rarely feels important on day one. It always turns out to be.
We think about this often because of a Learning Management System our team built for a UK client, on the cloud, around SCORM. Working to a standard rather than inventing our own format was a constraint at the time. In hindsight it was the point.
What a standard actually buys you
SCORM specifies how learning content is packaged, how it launches, and how it reports progress back to whatever platform hosts it. The value is portability: content built to the standard isn't married to one vendor's system — it can move. If the client ever wants to change platforms, their content and their records go with them. That is the opposite of lock-in, and lock-in is the thing serious clients have learned to fear.
The choice that decides whether a client is free or trapped
It rarely feels like a big decision at the time. SCORM specifies how learning content is packaged, how it launches, and how it reports progress — so content built to it is not married to one vendor's system.
| Criterion | e.g. SCORM | |
|---|---|---|
| Who can read the content | Only the system that made it | Any conforming platformthat is what portability means |
| Switching vendor | Rebuild, or staythe leverage is the point | Export and move |
| What transfers at handover | Access, while the contract lasts | Formats, docs, data and sourcegenuinely yours |
| Who the system depends on | The vendor standing next to it | Nobody in particularcloud architecture, done properly |
| The test at the end | Do you own a dependency? | Do you own the thing? |
From building a cloud, SCORM-based LMS for a UK client.
The quiet decision, made explicit: what each choice means years later, when the client wants to move.
The cloud part is about who can depend on it
Building for a UK client from Nepal meant the system had to be dependable without us standing next to it. That is what cloud architecture, done properly, gives you: availability, maintainability, and the ability for the client to rely on the system rather than on the builder's presence.
Ownership is a design choice, not a closing formality
The best signal that a vendor is building for the client's benefit rather than their own leverage is how the project ends. Open formats. Documented systems. Data the client can export in a form anyone can read. Source and knowledge that genuinely transfer. You can't retrofit that at handover — it has to be a decision made at the start and held to all the way through.
Five questions that decide whether you will own it
Ownership is a design choice, not a closing formality. The best signal that a vendor is building for your benefit rather than their own leverage is how the project ends.
| Ask the vendor | Answer that should worry you | Answer you want |
|---|---|---|
| What format is our content stored in? | Our own — it is optimised for our platform | An open standard any conforming system can read |
| How do we get our data out? | Raise a request and we will export it for you | Self-serve export, in a form anyone can read |
| Who can host this after you? | Realistically, only us | Any competent team — the architecture is documented |
| What transfers when we finish? | Access for the term of the contract | Source, documentation and the knowledge to run it |
| What happens if we leave? | Most clients find it easier to stay | You take it with you — that is the design |
The same test applies past e-learning: a learning platform, a monitoring system or a national databank.
What to ask before a project starts — not at the closing formality, when the answers are already fixed.
The principle, past e-learning
This isn't really about SCORM. It's a way of building. Whether it's a learning platform, a monitoring system or a national databank, the same test applies: when this is finished, does the client truly own it — portably, independently — or do they own a dependency on you? We think the answer should always be the former.
Frequently asked
What does SCORM give you?
Portability: content built to the standard isn't married to one vendor's system, and the tracking data follows open conventions — so if the client changes platforms, their content and records go with them.
How do you avoid vendor lock-in?
Open formats, documented systems, exportable data, and source code and knowledge that genuinely transfer at handover — decisions made at the start, not retrofitted at the end.
Want this run on your numbers?
We'll do the same analysis on one of your workflows in the two-week Automation Sprint.
Related service · Product Forge