Consumer AI
Nufeed
A personalised news feed that lets people design their own algorithm instead of inheriting one — taken from spec to a public test-flight in weeks.
<2s
per-topic feed rewrite latency
- Next.js
- LLM pipelines
- Content
Services
Reliability & scale
Making a system behave predictably under conditions you have not seen yet. Load modelled from real traffic shapes, failure modes worked through deliberately, and instrumentation that tells you something before a customer does.
When teams call us
If more than one of these is true, this is usually the right starting point.
Typically 3–5 weeks, often alongside a build.
- You find out about incidents from users
- A traffic spike is coming and nobody has modelled it
- On-call is noisy and most alerts are not actionable
What it covers
- Load modelling from real traffic shapes
- Failure-mode and dependency analysis
- SLOs with error budgets that mean something
- Alerts that map to an owner and an action
What you keep
- A load model you can re-run
- SLO definitions and dashboards
- An alert catalogue with runbooks attached
How it runs
How we approach it
The sequence this work follows, and why it is in that order.
Model the load you actually get
Traffic shapes taken from production, not a flat synthetic ramp. Real systems fail on spikes, uneven key distribution and retry storms — none of which a smooth load test reproduces.
Work the failure modes deliberately
Every dependency gets the same question: what happens when this is slow, and what happens when it is gone? Timeouts, retries and circuit breakers follow from the answers rather than from defaults.
Instrument to an owner and an action
An alert that does not name who responds and what they do is a notification. We delete those. What is left is a smaller catalogue that people actually trust at 3am.
Rehearse before it is real
Game days against the failure modes we found, with the runbooks in hand. The first time you execute a runbook should not be during an incident.
What we build with
The stack for this work
Chosen per engagement, not per fashion. If your team already runs something that works, we use that instead.
Observability
- OpenTelemetry
- Prometheus
- Grafana
- Sentry
Load
- k6
- Gatling
- Production traffic replay
Resilience
- Circuit breakers
- Bulkheads
- Backpressure
- Caching
Response
- PagerDuty
- SLO dashboards
- Runbooks
Evidence
Where we have done this
Before you ask
Questions we get about Reliability & scale
Also from us
The rest of what we build
Most engagements draw on more than one of these.
- Product engineeringBlank repo to production traffic. We own the architecture, the pipeline and the runbooks. You own a system your team can actually run.Learn more
- Web & mobile applicationsFast on a mid-range Android. Accessible to WCAG 2.2 AA. Built on a component library your team extends without calling us.Learn more
- AI features that shipAI that survives production. We build the evaluation harness first, so you know a change helped — not just that the demo looked good.Learn more
- Platform & cloudInfrastructure your team can run without a dedicated rotation. Reproducible, deliberately boring, and priced predictably.Learn more
- Legacy modernisationChange code nobody remembers writing. We map it, pin it with tests, then move it in steps you can revert.Learn more
Let’s talk
Need Reliability & scale?
One week, and you keep the baseline and the plan either way.