A Padlock Is Decoration
A training company sold every seat manually — a marketing page, an email, an invoice, no system anywhere in the loop. The engagement asked what it would take to sell and deliver that training online, and produced two things: a full design for the platform, and a front-end prototype of every screen so the decision could be made by walking through the product rather than reading a spec.
The prototype covers the catalogue, the preview-and-lock curriculum, checkout, the course player with progress and resume, a learner dashboard, and an admin area with a curriculum builder. A floating "Viewing as" control switches between visitor, learner and admin instantly, so a stakeholder sees all three sides in one sitting without credentials.
The more interesting half was the design pack, and the conclusion that shaped most of the code.
Where the boundary actually is
Entitlement — may this person watch this video — is defined as one server-side function, called at the moment the content is requested. Not at page load. Not when the route renders. At the moment the bytes are asked for.
The reason is worth stating bluntly, and the prototype's README states it: a padlock icon is decoration. It is a hint to an honest user about what they have not bought. It is not a control. Anyone can open devtools and flip the flag that draws it, and if that flag is also what gates the content, they now have the content.
The only thing protecting a paid course is that the video playback token does not exist until the server has checked. Everything else is user interface.
So the README says, in as many words, that the prototype's own lock is presentational and must not be copied into production. That sentence exists because prototypes get mined for code. Someone will lift the lock component — it looks finished, it behaves correctly, it is right there — and the only defence against that is to write down, next to the code, that it is a drawing of a lock.
Only the webhook may grant access
The second rule: the payment webhook grants access, never the browser redirect.
The redirect back from a payment provider is a URL. It tells you the user's browser ended up somewhere, which is not the same as money having moved. Treating it as proof of payment is one of the most common ways a checkout leaks product.
Which creates a real design problem, because the webhook is asynchronous and the user is sitting there. The resolution is to be honest in the interface: the confirmation screen deliberately sits in a "confirming your payment" state and polls, rather than assuming success and quietly correcting later. Slightly slower, and it never tells someone they own something they do not.
Modelling that survives contact with the business
Two more decisions earned their keep. Courses and cohorts are separate entities, because a course has several dated intakes and an order must record which one was bought. Folding them together is the kind of simplification that looks clean until the first refund request for the March cohort.
And money is stored as integer minor units with an explicit currency — because the existing prices were ambiguous dollar figures, for courses delivered in Riyadh and Dubai, by a Canadian company. "$1,200" is not a price. It is a price and a question.
Arguing against your own scope
The design work also pushed back on the sequencing. Management wanted payments first. As briefed, that would have meant taking money for self-paced content that did not yet exist.
The re-plan sells seats in the scheduled instructor-led courses the business already runs — deliverable without a line of content-platform code — and defers the platform to a later phase. On the documented estimate it moves first revenue forward by roughly three months.
The delivery plan also argues, against its own commercial interest, that building should be compared honestly against an off-the-shelf platform before committing. That belongs in the document. A plan that cannot say "you might not need this" is a sales deck.