Emergency and safety training platform

The challenge

Emergency response credentials expire. Qualified first aid has to be renewed on a cycle, and renewal usually means several days of leave and travel to an in-person course. For a volunteer firefighter or anyone holding down a job, that is a real barrier, and it has nothing to do with how good they are.

The market is fragmented on top of that. The knowledge sits in one place, the tests in another, the certificate in a third. Learners assemble it from several unconnected providers and start from scratch every time they switch.

What they end up with is a paper certificate an employer can do very little with. It cannot be verified or slotted into a formal process, and employers and public bodies are usually the ones paying for the training.

What we built

A training platform for emergency response and civil safety that joins online learning to certified field training. Four disciplines under one brand: qualified first aid, tactical combat casualty care, survival and tactics. Theory and testing happen in the app, and only what genuinely cannot be done remotely stays in the field.

Access works on two levels, and that is the heart of the product. The open tier is articles and quizzes, no login and no payment, available to anyone. The paid tier is full courses with video, offline material, an exam and a PDF certificate carrying a QR code, which an employer can check on a public verification page without creating an account.

The platform in numbers (as of July 2026)

19 tables, 18 RPC functions and 34 hand-written, forward-only SQL migrations deployed from CI

14 courses in the database, including the first full production course with scenarios and quizzes

10 articles and 5 quizzes in the open tier, available without signing in

3 Edge Functions on Deno 2: the payment webhook, certificate issuing and signing video URLs

78 Playwright end-to-end tests, 67 of them security tests, plus 20 unit test files

6 parallel CI jobs, from types and linting to migration parity and the security suite

The hardest problem: security you cannot route around

The key architectural decision reads like this: the security boundary is the database, not the application layer. Postgres enforces permissions through Row Level Security. The web layer stops a request before it reaches the render, but even if someone got past it, the database simply will not hand over anyone else's data.

In practice that means three things. A course enrolment cannot be inserted from the client at all; only the payment webhook running on the service role does that, with idempotency, so the same event never writes twice. Role escalation is blocked by triggers and audited in a separate table. Lesson access is gated by a database function rather than a condition in a component.

What matters most is that these rules are tested against a live project rather than mocks. 67 security tests check them on every deployment. A rule nobody tests is just a good intention.

Regulations as the foundation, not an add-on

CI watches accessibility. An axe-core audit runs automatically alongside the browser tests, so an accessibility regression cannot slip quietly into production.

For GDPR, protection is built into the architecture rather than bolted on at the end: Row Level Security on every table holding user data, encryption of offline material, an audit log of role changes, and a private video bucket whose URLs are signed and expire after 6 hours.

The engineering you do not see

One monorepo, two clients, one backend. Eight packages are genuinely shared between web and mobile: database, auth, domain logic, design system, brand, payments, validators and analytics. The mobile app draws on the same design tokens as the web.

Offline mode is a non-trivial piece of mobile engineering. The app downloads video lessons behind a WiFi gate and a storage limit, with a FIFO queue that survives navigation, and encrypts them with AES-256 on disk. Course material never sits on the phone as a plain file.

Multi-brand support was designed in from the foundation. The second brand, a civilian version for local government, comes from a config file rather than a fork. Names, taxonomy, navigation, seller details and feature flags are lifted out of the components, and CI guards the shared database schema so the two deployments cannot drift apart unnoticed.

Deliberate decisions about what we do not do

Hosting is our own: a multi-stage, non-root Docker image with a healthcheck, running on Coolify. Deliberately no Vercel.

Video lives in a private bucket behind signed URLs instead of a paid video host. Payment is one-off per course, by card or BLIK, with no subscription, because the product does not need one today. Each of those decisions means fewer bills every month and fewer things that can surprise us as it scales.

The interface philosophy is just as firm. The design system calls it "Equipment, not Interface": a tool someone reaches for in a critical moment should be precise and predictable, with nothing decorative in the way. Dark interface, monospace, hairline rules, no shadows, and the orange accent reserved for the single call to action. Deliberately no gaming aesthetic and no military kitsch.

What comes next

The product is pre-launch. We are closing the last pieces and preparing a pilot with the first groups. We build it as a product of our own, so everything we learn here about data security, mobile apps and running two brands on one codebase ends up in our clients' projects.