One HTML file vs. a web application: sample intake without the IT-approval gauntlet
A web application to collect sample requests — or to show clients the results of their analyses — has never been easier to build. The hard part was never the code. It's getting IT to approve any kind of systems development: a server, a login, a database. At a public research organisation that approval is a real wall, and it's why good tools die in the queue.
So the gap between a PDF/Excel form and a working web app looks enormous. But there's an intermediate step that costs nothing and asks no one's permission to run: an HTML file.
The step in the middle
Almost every computer already has a modern web browser. Open an HTML file as a file — double-click it — and its code and its data touch the internet not at all. There is no server, no connection, nothing to approve serving. But inside that sandbox you get real tools: JavaScript, the browser's Web Crypto API, even a full SQLite database. That is far more than a PDF or an Excel sheet can do.
Chief among what it unlocks: the file can compose the data you enter into a scannable QR-code label. Scan it at the lab and the request lands as structured data — transcription never has to happen. Every lab request that arrives as a document gets re-typed into the system; this is the step that removes that cost entirely.
Excel already goes part way — it's structured and travels as a file — but it still gets emailed and re-entered. The QR is what closes the last mile.
The file the user fills out
Take a concrete case — Juárez Research Centre, with ISO/IEC 17025-accredited environmental and geoanalytical labs, taking work in through documents. Here is the HTML file a client opens to make a request — no install, no account, just a browser.
One fill, three outputs
From that single fill, the file exports the request three ways — the PDF and Excel are for people; the QR (above) is for the machine.
How it works, briefly
It's all the browser's own Web Crypto — no libraries — and the choices sit inside CSE's approved set (AES-256-GCM, PBKDF2-SHA-256, ECDH/ECDSA on P-256, SHA-256).
- Structured & validated at the source, so the output is machine-readable and never re-keyed.
- The QR is DEFLATE-compressed (≈40% smaller — a full multi-sample request fits a version-18 code a phone scans cleanly).
- Content-addressed sample IDs (a hash of each sample's data) — tamper-evident, collision-free across devices, no central counter.
- Encrypted at rest under a PIN; the shipped page carries a Content-Security-Policy whose keystone is
connect-src 'none'— the page cannot open a network connection. What you type has nowhere to go but the file you export. - Results can return sealed to the client (the request carries the client's public key; the lab encrypts the report to it), so only the requester can open them.
Why a downloadable file clears the approval bar
Restating the case plainly: serving a web application pulls the full weight of institutional governance — an IT security / threat-risk assessment, a privacy review against your jurisdiction's access-and-privacy law, data-residency and retention questions, vendor onboarding and procurement, and an ongoing operational and liability footprint. Months, not days.
Posting an index.html as a download is a different act entirely. It's a file on a page; the user clicks it and opens it in the browser they already have — no software required on their side, no server to assess, nothing leaving the device to review, no account, no vendor operating a system on the organisation's behalf. It behaves like handing someone a PDF: a tool a person runs, not a system the institution operates. That's the difference between "interesting demo" and "in use next week." (Governance doesn't vanish once real custody records are involved, and none of this is legal advice — the point is that the barrier to starting is a fraction of a web app's, because there is no system to stand up.)
A no-server on-ramp to a real web app
And it needn't stay a one-off form. The user can keep a local history file — export the (encrypted) database and import it before the next session. With that, the same downloadable file offers what people usually stand up a web app for: a dashboard of previous requests, the results that came back for each, and simple analysis and charts over them — all with no web server at all. The history lives in a file the user controls.
It's also a clean prototype. If the Centre ever decided to build a hosted client portal — real accounts, a shared dashboard, cross-request analytics — this is the starting point: the same data model, the same forms, the same exports, already validated end-to-end. Start as a download; graduate to a web app only if and when the value justifies the approval process.
How to use it
Client (the requester): open the file → choose a form → fill it (formats checked as you go; add samples and pick their test panels) → export as PDF, Excel, or QR. Optionally sign in (a PIN) to save requests and reuse profiles.
Lab (intake): open the lab file → scan the request QR (or paste the string) → it lands on a kanban board, columns by sample type, filter by client, advancing Received → Prep → Analysis → Reported → Complete. Export to Excel/JSON, or export the whole encrypted database to hand off. Two stations can each export and merge with no conflicts.
The code
It's open source — two Vite/TypeScript apps (client + lab) that build to single self-contained HTML files, plus the offline chain-of-custody and crypto core:
github.com/rheophile10/sample-forms
Where to start
Not the C-suite. The person who already dragged their intake toward digital: whoever owns the Geoanalytical "Request for Laboratory Services" — the sort who moves a form from PDF to Excel on their own initiative, exactly the disposition that adopts the next rung. Hand them the client file pointed at their real form. It costs nothing to try and touches no institutional system to do it.
— built and verified end-to-end (form → QR → lab kanban → sealed report → decrypt → visualise) before writing a word of this.