Fast, and actually right.
When the catalogue, inventory or content grows past what a spreadsheet can survive. Query planning, indexing, caching strategy, and Elasticsearch tuned for your data — not its tutorial. We treat relevance as a measurable engineering problem, not a vibe.
You can't tune what you don't measure.
Most performance problems are travel, not work. The CPU is bored; the page is waiting. Most search problems aren't search problems either — they're data-model problems wearing an Elasticsearch costume. We start by measuring, on real data, on a real network, before we change a line.
An engagement opens with a profiling pass: production traces, query plans, a relevance test set built from your actual queries. We come back with a ranked list of changes, each with an expected and then a measured impact — so the work is accountable, not anecdotal.
We hand over a system that stays fast: budgets in CI, a relevance harness that fails the build when results regress, and dashboards that tell you the day the catalogue outgrows the current plan — before your customers do.
Measure, model, tune, lock in.
Four phases bound together by one rule: every change has a number before and after.
Measure
Production profiling on real data and real networks. Query plans, traces, and a relevance test set built from your actual search logs. A baseline nobody can argue with.
Model
Often the real fix is the data model: how you index, denormalise, shard or partition. We design the model for the questions you actually ask.
Tune
Query rewriting, analyzers and synonyms, caching layers, edge strategy. Each change measured against the baseline — kept only if the number moves.
Lock in
Performance budgets and a relevance harness in CI, so the gains don't quietly erode over the next year of feature work.
What we actually do.
The places software gets slow, and the places search gets wrong.
Elasticsearch tuning
Mappings, analyzers, relevance scoring and shard strategy tuned for your domain. Hospitality data especially — rate plans, occupancy, amenities.
Query & database optimisation
Reading query plans for a living. Indexing, denormalisation, partitioning, and the occasional hand-written SQL that replaces a slow abstraction.
Caching & edge strategy
The right cache at the right layer with an invalidation story that holds. CDN, application and database caching that don't lie to each other.
Front-end performance
Core Web Vitals as an engineering target. Collapsing request waterfalls, trimming bundles, fixing the layout shift that nobody owned.
Relevance engineering
Search quality measured, not guessed. Judgement sets, offline evaluation, and A/B'd ranking changes that move the metric you care about.
Capacity & observability
Load modelling and the dashboards that warn you before the catalogue outgrows the plan. Knowing the cliff before you reach it.
Tools we keep returning to.
Measurement first, then the smallest change that moves the number.
Vespa · pgvector
ClickHouse · PostGIS
Varnish · CDN
OpenTelemetry · Grafana
Recent speed work.
Numbers we're allowed to share. The rest are under NDA.
Nine seconds to 1.4
Collapsed a waterfall of nine sequential API calls into two parallel ones. Time-to-useful from ~9s to ~1.4s; conversion recovered 2.4×.
4M SKUs, 12× faster
Hybrid Postgres + Elasticsearch model replacing a Postgres-only catalogue. Search latency under 80ms at p99 across four million SKUs.
Search that understood rooms
Re-modelled rate plans and occupancy so the right room ranks first. Zero-result searches down 70%; assisted bookings up.
A cache that told the truth
Re-architected an invalidation strategy that had been serving stale prices. Cache hit rate up, support tickets about "wrong price" gone.
Related services.
Speed work rarely arrives alone. These usually come with it.
Something slow,
or searching wrong?
Tell us a little about what's dragging. We reply within two working days, in plain language, with an honest read on whether we're the right team.