Work
Systems we built, and what they cost us to get right
These are our own products, not client engagements. Client work is not ours to publish, and dressing internal systems up as customer references would be exactly the thing this page exists to avoid.
What they are good for is that you can check them. Every result below says how you would verify it, each one names what the system does not do, and one of them you can go and run in this browser without an account.
Running untrusted code with no server to attack
Two teaching runtimes that execute a learner’s C and Python in their own browser.
Who it is for
Someone learning to program on techmonster.dev, who wants to write code and see it run before deciding whether to create an account.
The problem
A learning site that lets people run code normally has to execute code it did not write. The standard answer is a sandboxed container per submission, which means a queue, a per-run cost, an isolation boundary somebody has to keep correct, and an attack surface that grows with traffic.
The second problem is pedagogical rather than operational: a real compiler reports a beginner’s mistake in the vocabulary of the compiler. "Segmentation fault" is true and teaches nothing.
Constraints
- ·No per-run infrastructure cost at any traffic level.
- ·No account required, so no identity to rate-limit against.
- ·Must not be able to harm the person running it, or us.
- ·The same program must produce the same output on any machine, or an exercise cannot be graded.
What we did
- ·Execute in the visitor’s own browser instead of on a server. There is then no server executing untrusted code, so there is no sandbox to escape and no per-run cost to meter.
- ·Write the runtimes rather than embedding an existing one, so the diagnostics can be written for a beginner and so undefined behaviour can be reported rather than imitated.
- ·Bound everything — steps, wall clock, output size, call depth, memory — so a runaway program ends in a sentence rather than a frozen tab.
How it is built
- ·C: lexer, preprocessor, parser and a tree-walking interpreter over a byte-addressed memory with per-byte initialisation tracking, so reading uninitialised memory, running off an array and use-after-free are detected at the moment they happen.
- ·Python: an indent-stack lexer, recursive-descent parser and interpreter with arbitrary-precision integers and Python’s floor-division semantics, plus a standard-library subset and a virtual filesystem the exercise supplies.
- ·Both are pure functions of (source, input, files): no eval, no network, no DOM access, and no clock the program can read.
What is true, and how you would check it
No server executes visitor code, so the per-run cost is zero at any traffic level.
The runtimes are client-side modules; there is no execution endpoint to call.
The same program produces the same output every time, which is what makes automated checking possible.
rand() is seeded and the clock is fixed; the test suite asserts repeated runs are identical.
375 automated tests cover the runtimes, the checker and the exercise content.
The repository’s own test suite, run on every change.
Every authored exercise solution is executed against its own tests by the suite, and every starter is asserted not to pass.
A broken or accidentally-solved exercise fails the build rather than reaching a learner.
What it does not do
- ·They are subsets. Both runtimes refuse what they do not implement by name rather than approximating it, and every screen that runs code says so.
- ·They are teaching runtimes, not the toolchain a real project uses. Nothing here claims to reproduce a full Linux system.
Run it yourself — no sign-up →
Closest engagement: Bounded Pilot · discuss something like this
Giving every new user their own private repository, with nobody in the loop
Sign-in to a provisioned private repo, with a signed callback contract and a reconciler that fixes what got stuck.
Who it is for
A learner who signs in and needs a private working repository created, and an advisor who approves the paid ones.
The problem
Creating a repository per person by hand does not scale past the first few, and it fails in the ways manual work fails: someone is on holiday, someone forgets, someone does it twice.
The interesting part is not the happy path. It is what happens when a dispatch is delivered and the callback never arrives, when the same request is retried, and when an invitation expires before it is accepted.
Constraints
- ·No metered CI minutes.
- ·A user can write their own profile data directly, so no privileged decision may be made from anything they control.
- ·A retry must never produce two repositories.
What we did
- ·The website dispatches a job; a private control repository runs it on a self-hosted runner; the job calls back when it is done.
- ·Every request carries a deterministic idempotency key, so a redelivery is recognised rather than duplicated.
- ·A scheduled reconciler re-drains anything that was dispatched and never confirmed, and re-invites expired invitations — because the fix for "the callback did not arrive" is a job that notices, not an alert somebody reads.
How it is built
- ·One HMAC signing rule for every direction: sha256 over timestamp, method, path-with-query and the raw body, inside a five-minute window — so signature checking is the same code on both sides and cannot drift.
- ·The callback answers 200 for a duplicate or superseded request and 4xx for permanently bad input, so the sender retries only on 5xx and transport errors instead of hammering on an input it will never accept.
- ·Authorisation reads the verified identity claim, never the copy stored in the user’s own profile.
What is true, and how you would check it
Provisioning consumes no metered CI minutes.
Jobs run on a self-hosted runner; the hosted runner is a manual fallback only.
A redelivered or retried request cannot create a second repository.
The idempotency key is deterministic per attempt and checked in the workflow ledger.
A run that gets stuck is recovered without anybody noticing it.
A scheduled reconciliation re-drains unconfirmed work every few hours.
What it does not do
- ·It provisions repositories from templates. It is not a general-purpose workflow engine and was not built to be one.
- ·It depends on a code host’s API and inherits that host’s availability.
Closest engagement: Bounded Pilot · discuss something like this
Publishing a curriculum without leaking the answers
Authored content compiles to a public catalog the website reads, with a guard that refuses to publish grading material.
Who it is for
Whoever writes the curriculum, and every page on the site that shows what is taught.
The problem
The source material for a course contains two kinds of content that must never mix: what the learner reads, and the rubric, viva prompts and grader signals used to assess them. They live in the same folder and are edited in the same sitting.
Separately, a marketing site that hardcodes "22 tracks" is wrong the week a track is added, and nobody notices because nothing errors.
Constraints
- ·A single mistake must not publish an answer key.
- ·The website may not hold its own copy of the catalog, or the two drift.
- ·A publish must be safe to run repeatedly.
What we did
- ·One exporter compiles authored source into a public catalog, stripping assessor-only material on the way out.
- ·The consumer parses that catalog with a second, independent guard that walks the whole document and REFUSES it if grading material is present — so a leak has to get past two locks written at different times.
- ·The website derives every count and every track name from the catalog at request time. There is no fallback list, because a stale list is worse than an honest "unavailable".
How it is built
- ·Export-time strip plus parse-time refusal; the parser throws rather than rendering a document containing forbidden keys or grader-signal text.
- ·Content is versioned with the curriculum, so a page and the material it describes move together.
- ·Pages fail visibly when the catalog cannot be reached, rather than showing a number from last week.
What is true, and how you would check it
22 tracks and 953 projects publish through the pipeline, with the leak guard passing.
The exporter reports both counts and the guard result on every run.
No track, count or project name is hardcoded in the website.
Every one of them is read from the published catalog; the pages render an explicit unavailable state when it cannot be read.
Republishing changes only what actually changed.
The last publish reported 3 files updated and 20 unchanged.
What it does not do
- ·The guard refuses known shapes of private material. It is a safety net under an export step, not a proof that nothing private can ever be written into a public field.
- ·It publishes a catalog. It is not a CMS and has no editing interface.
See the live catalog on the site →
Closest engagement: Ongoing Delivery · discuss something like this
Your workflow is not one of these
It never is. What these show is how we work on a problem: what the constraints were, what we refused to fake, and what we will tell you the system cannot do. Describe yours and we will tell you which parts we think are actually hard.
Describe your workflowLooking for the browser-only tools instead? They are on the products page.