Hosted Delivery Platform

Twenty-four products opened as a website instead of shipped as a ZIP — eleven open, thirteen gated. Access is a code that unlocks one product, so there are no accounts, no passwords, no email capture and no record of any buyer stored anywhere. Alongside the site sits the release process: eighty-three products that have already been sold are locked read-only, with checks around every release confirming that what goes out is what was built.

Products delivered as ZIP downloads fail in predictable ways. The archive unpacks into a downloads folder, the folder is renamed, relative links break, and managed school devices often refuse to open local HTML at all. Every one of those failures arrives as a support request from a teacher who simply wants to open the thing. The standard remedy is a website with user accounts, which carries two costs that were not acceptable here: collecting personal data about educators and their schools, and running an account system single-handed.

People who have bought a product and want to open it, often on a school device, often on the second day of term.

• The access model, and the decision not to hold identity at all
• Operating the hosting, the access gate and the release process
• The privacy position, and the packaging changes it forced

What the design set out to achieve. These are objectives, not results.

• Replace the ZIP with a URL that keeps working
• Collect nothing about anyone
• Let access survive a school year on the same device without a login
• Make sure a released artefact cannot be quietly changed under someone who already bought it
• Build a front door that is not a shop

A buyer reaches a product through a code, not a login. The code unlocks one product for a set period and cannot be reused against a different one. Nothing about the buyer is recorded anywhere — no account, no password, no email address — so there is nothing about a buyer to protect, to lose, or to be asked to hand over. Repeated wrong attempts are slowed automatically. What traffic information exists comes from the server’s own records rather than from anything running in a teacher’s browser: no cookies, no identifiers, no third parties.

This is infrastructure, and the useful role for AI here was adversarial: repeatedly asking how the access design fails, what someone does with a code they should not have, and which of the convenience features being proposed would quietly reintroduce identity. Drafting the setup was the smaller half. The system itself contains no model and calls nothing outside itself.

The privacy and compliance position is a business decision with legal edges, not a technical preference, and it was taken deliberately rather than arrived at. So was the release lock, which is a self-imposed constraint that makes routine work harder and exists precisely because it makes carelessness harder too.

Designing access with no identity means giving up everything convenient about a login. There is no “resend my code”, no account recovery, no way to look up who has access to what, and no way to contact anyone about a fix. Each of those has to be answered somewhere else — in the packaging or in the product itself — and working through that list is most of the real work in this system.

The release side of the platform is where the iteration is recorded. What began as a build-and-upload step accumulated a check that what is served matches what was built, a check before publishing, a record of exactly what went out, and finally the read-only lock over the eighty-three products already sold. Each of those exists because release is the point at which a mistake becomes someone else’s problem.

No adoption or revenue figures are claimed here and none are implied. What is verified is the shape of the thing: twenty-four hosted products, thirteen gated and eleven open, eighty-three locked releases, live and responding. Whether buyers prefer it to a ZIP is not something I have measured, and it would be easy to assert. The part I would defend regardless of usage is the decision to hold no personal data, because that one is right whether or not anybody notices it.

• Access and delivery design
• Privacy by design
• Service operation
• Release process design
• Privacy-preserving analytics
• Product packaging and delivery