WOLSTAPP

Solutions & Software Architecture

Good architecture meets three demands at once: what the product needs to ship this quarter, what the team needs to absorb in six months, and what the business is becoming in two years. Most consultancies pick one and call it a methodology. “Ship the MVP” buys speed; what ships is also what you’re rewriting after the next funding round. “Build for scale” buys durability for a future that hasn’t arrived; the feature that would land the next ten customers stays in the backlog.

We refuse the trade-off. Architecture decisions split into the reversible and the irreversible — and senior judgement is knowing which is which. The reversible ones we make fast and keep moving. The irreversible ones — data shape, identity, service boundaries, deployment topology — we hold up to the eighteen-month plan before they’re committed.

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

Bespoke Software & App Development

We build software that solves the problem behind the ask. By the time a feature request reaches the engineering team it has been compressed into a sentence — a translation of something upstream: a user pattern, an operations constraint, a margin under pressure. We treat that sentence as a hypothesis, not a specification.

Every engagement starts with the upstream conversation — with whoever owns the constraint that produced the ask: the user, the data, the team running operations. The spec gets written from that conversation, not from a kick-off whiteboard. Sometimes the answer is the feature as requested. Sometimes it’s a smaller change to an adjacent system. Sometimes it’s the realisation that the wrong thing was being asked for, and the engagement starts over.

bespoke-dev

Reframing a live-screen ask as a latency-budget problem

The ask was small and concrete: build a live game-view screen — a single real-time surface inside an already-shipping platform. By the time we were inside the codebase, the request had become a different conversation. The constraint wasn’t the screen. It was where the system’s end-to-end latency budget got spent: feed ingestion, transport, processing, persistence, render. Each layer was quietly using its share.

We built the screen, shipped it, and watched real-world testing surface the shortcomings the engineering team had warned about. Days later we re-architected. The substrate that landed treated latency budget as a first-class concept the application could observe and reason about — not a property emerging from the implementation. The original feature got rebuilt on top of it.

Subsequent real-time features inherited the substrate without revisiting the budget conversation. The pattern paid for itself by the second build that used it.

  • Original ask: a single real-time game view; actual constraint: every layer of the stack was spending its share of a tight end-to-end latency budget
  • Built a substrate that exposed the latency budget as a first-class concept rather than a property emerging from the implementation
  • Days after real-world testing surfaced shortcomings in the initial build, we re-architected — the substrate landed and the original feature got rebuilt on top of it
  • Subsequent real-time features used the same substrate without revisiting the budgeting question

AI Enablement / Integration / Consultancy

AI is best used to augment humans, not to replace them — and the right place to apply it is wherever the team’s week is being drained by work they hate doing. The “AI will transform your industry” framing is the dominant one in the market right now; we reject it. Cost-cutting through headcount reduction is a different consultancy’s offer.

We talk to the team before we touch the model. The week gets mapped — the half-hour task done every day, the report nobody reads, the queue that always backs up on Monday. That’s the AI target, not the executive’s wish-list. The drain is bottom-up; it’s the operator who knows where the energy is leaking. Build the AI there, and you unlock the time that lets the team do work that actually requires them.

ai

Operational AI that took surveillance off the operator's screen

The platform ran a distributed venue-tier and a thin central plane. The drain was on-call cognitive load — operators watching every game, every venue, every integrator for things that quietly went wrong. The AI question wasn’t “what can we generate?” It was “what can we stop asking people to monitor?”

We built operational AI on top of the existing telemetry: anomaly detection across venue stacks, queue prediction for integrator backpressure, system-health rollups. The substantive engineering decision wasn’t the model — it was the eval scaffold. Evaluation measured whether the AI assisted the operator’s judgement, not whether the model’s outputs looked plausible. The operator stayed the source of truth; the model was an instrument. We also refused a separate AI feature the business side wanted because it would have demoed well without removing a real drain.

Operators stopped watching live games and started reviewing exceptions. The surveillance work disappeared; higher-judgement work expanded into the space.

  • Operational AI surface: anomaly detection across venue stacks, queue prediction for integrator backpressure, system-health rollups
  • Eval scaffolding measured the AI's effect on operator judgement, not the model's own confidence — the operator stayed the source of truth
  • Refused a separate AI feature the business side wanted because it would have demoed well without removing a real drain
  • Operators shifted from watching live games to reviewing exceptions — surveillance work disappeared, higher-judgement work expanded

Our Projects

We build our own products on the site for the same reason we put our work in front of a referral: nothing demonstrates engineering discipline like applying it to something we own. The dominant alternative — a consultancy that “focuses on client work” and quietly outsources its own technical bets — protects the brand by avoiding the audit trail. We do the opposite. The architecture decisions, the build choices, the AI integrations we apply for clients are all on display in a product we built from zero.

A product we ship and maintain is unforgiving in a way that case studies aren’t. It gets used. It breaks. It scales, or it doesn’t. The consequences land on us, not on a client who can’t be named. That’s the standard we hold our client work to, and the product is the public proof that we hold it.

Stillvault

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