Senior engineering at startup velocity.

No junior hand-off.

Our flagship product

Stillvault

Stillvault

Human-in-the-loop secret management.

Phone-biometric-bound secret release for servers and AI agents. Nothing moves until a human says so.

A server or AI agent needs a credential — a database password, an API key. Instead of leaving it decryptable on an always-on box, Stillvault keeps it encrypted at rest under a key your phone holds. When the secret is needed, the server asks your phone; you approve with your fingerprint; the release happens in your phone’s secure hardware and the server gets the plaintext for a short, time-boxed lease, then forgets it.

The server can’t decrypt unaided — and, as a SaaS, neither can we. A fully compromised server or a breached vendor holds nothing but ciphertext. Proven end-to-end on real hardware; now being built out as a SaaS.

Visit Stillvault

Proof, not promises

An unusual architecture call — every venue runs its own containerised stack — that turned out essential once games started losing connectivity in the wild.

architecture

Edge-deployed venue compute for live sports operations

The product was a new-concept real-time sports operations platform — a small team, multiple third-party integrators, and a tight delivery window against a category nobody else had tried. The architectural question was where compute should live: the 2026 default would route everything through a central cloud tier.

We chose to put it at the venue instead. Each venue runs an identical containerised Node web stack; central holds cross-venue ops. Outside live games the architecture looks more expensive than the cloud-only alternative. During live games the trade-off inverts: games can’t pause because connectivity dropped.

Games kept running when networks failed. Local interactions ran at sub-100ms feedback loops. Adding venues scaled near-linearly because most load lives at the edge, not central. The operational tax is real — running infrastructure at N venues is harder than running it in one cloud — and we’d still make the same call.

  • Each venue runs an identical containerised Node web stack, kept current via image-pull updates
  • Event-driven sync-back to a central store; venues are the source-of-truth during games, central is source-of-truth across them
  • Multiple third-party integrators connect at the venue tier, not centrally — N venues scale near-linearly without proportional central load
  • Sub-100ms feedback loops on local-game interactions that would be impossible from the cloud

About Wolstapp

We’re engineers who finished the management ladder and chose to keep building. The architecture authority, the team leadership, the title — they happened earlier in the career; we made the deliberate choice to stay close to the work.

The working style is conversations first, code second. Most weeks open with the upstream conversation that frames the work and close with a demo. Code is what happens between them. Software quality is a moral position for us, not just a craft preference — bad code costs the team that maintains it, the users who hit the bugs, and the operators who get woken up.

Ready to talk?

Drop us a line — we respond to every message.

Get in touch