Skip to content
The Stacklumen platform is in private alphaSee the products

Your site makes promises.
We make it keep them.

Engineering support for companies whose websites have outgrown the teams keeping them. We read your codebase end to end, trace every broken customer path to its cause, and ship the fix through your own release process.

Send us a broken page See the cases
A drawn listing page for an illustrative retailer. As found, a pickup filter returns items the store cannot hand over, and the audit lists three failures. As fixed, every result can be picked up today.
To a first reply
1 business day
To a fixed, written proposal
3 business days
Where the fixes land
Your repo, your pipeline
Replatforming required
None

Big sites rarely break loudly. They break at the counter.

A filter that returns what the store doesn’t have. A store that’s forgotten at the cart. A buy button under a cookie notice. Each one is small, each one is a customer who leaves, and each one is decided somewhere in code that several teams have touched for years. That is where we start.

Pickup, offered and refused. On the same page.

The product page says the shoe is available for pickup today. The customer picks a size, presses the button, and is told the item is not eligible for store pickup.

Where it broke

  1. search/facets Eligible: read from a stock export refreshed overnight.
  2. product/fulfilment Available: read live from the store, without the size.
  3. cart/eligibility Refused: read a ship-only flag in the catalogue.

The fix

One eligibility check, by store and by size, that search, the product page and the cart all call. The three answers became one.

A contract test fails the build whenever any two pages would give a customer different answers.

As found: pickup offered on the page, refused at the button. As fixed: one answer, by store and by size, from search to cart.

The store, forgotten. Between two pages.

The customer chooses their store on the product page. At the cart, every item is back to shipping, the store reads "not selected", and a shipping charge appears.

Where it broke

  1. store/picker Saved the store in a cookie scoped to the shop’s own host.
  2. checkout/app Runs on its own subdomain, so it starts with no store at all.
  3. cart/defaults With no store, falls back to ship-to-home and adds shipping.

The fix

The chosen store lives in the customer’s session on the server, and every page, the cart and checkout read it from there.

A scripted customer chooses a store, checks out and confirms it on every deploy.

As found: the store chosen a page ago is gone, and shipping is charged. As fixed: the store follows the customer from the product page to payment.

The buy button, under three layers.

On a phone, a sign-up offer, a cookie notice and a chat prompt all open at once, and the sticky Add to cart button sits underneath every one of them.

Where it broke

  1. marketing/offer-modal Opens after two seconds, on the top layer.
  2. consent/banner Pins itself to the bottom edge, on the top layer.
  3. support/chat Floats over the corner, on the top layer.

The fix

One overlay manager decides what may cover the page, one thing at a time, and nothing is allowed to cover the buy button.

A phone-sized journey test fails if the buy button is ever covered or out of reach.

As found: an offer, a cookie notice and a chat prompt, all over the button. As fixed: one layer at a time, and never over the buy button.

Kestrel is an illustrative retailer. Each case is a composite of failures common on large retail sites, and the code paths are simplified for reading.

From codebase to fix. Without a rebuild.

Large sites are layers of decisions made by different teams in different years. We read all of them before changing any of them, so each fix lands in the one place that decides the outcome.

  1. Read the whole codebase

    With read access, we map every path a customer takes through your code: search, listings, product pages, cart, checkout and account. For each promise the site makes, we find every place that decides it.

    A map of where each customer promise is decided

  2. Trace each failure to its line

    Every reported issue is reproduced from a real customer path and followed to the code that causes it. Then the list is ranked by how many customers meet it and what it costs you when they do.

    A ranked list, each item traced to its cause

  3. Ship small, reviewed fixes

    Fixes go up as small pull requests through your own review, tests and release process, behind flags where it matters. Your engineers see every line before it ships.

    Pull requests in your repository, every sprint

  4. Hold the fix in place

    Each fix ships with the test that keeps it fixed: contract tests between services and scripted customer journeys that run on every deploy, so the same failure cannot come back quietly.

    Tests that run on every deploy

What we look for. On every path that earns money.

The audit follows the customer, not the org chart. These are the places corporate sites most often say one thing and do another.

  1. Fulfilment

    Pickup, delivery and stock that agree.

    Every page gives the same answer about where, when and whether a customer can get the item.

  2. Pricing

    The price on the card is the price at checkout.

    Sale prices, member prices and promotions resolved in one place, not recalculated per page.

  3. Search and filters

    Filters that return what they say.

    Facets, sizes and availability that match the catalogue and the store, with no empty results for things in stock.

  4. Checkout

    Nothing between a customer and paying.

    Overlays, redirects, lost sessions and forms that clear themselves, found and removed from the path.

  5. Accessibility

    Usable with a keyboard and a screen reader.

    Tested against WCAG 2.2 AA on the paths that earn money first, then everywhere else.

  6. Speed

    Pages that answer quickly on a phone.

    Core Web Vitals measured on real paths, with third-party scripts held to a budget.

  7. Measurement

    Analytics that match what happened.

    Events checked against real orders, so the numbers your teams decide on are the true ones.

Agile support. Not another replatform.

A standing engineering team that keeps your site in step with what customers expect, sprint after sprint, inside the systems and the process you already run.

Your stack stays.

Hosted commerce platforms, headless front ends and custom builds. We work in what you run today, and never make a rebuild the price of a fix.

Your team stays in charge.

We work beside your engineers, product owners and other agencies, in your tickets and your rituals. You approve every change.

A standing team, by the sprint.

The same engineers each sprint, so what they learn about your codebase compounds. Scale up for a season, down when it is quiet.

Questions your team will ask.

Answered here, so this page can go to engineering, security and procurement as it is.

Do we have to replatform?

No. The work happens in the codebase you have, on the platform you run. If a rebuild is ever the honest answer for one part of the site, we will say so in writing, with the reason, and it stays your decision.

What access do you need to start?

Read access to the repositories behind the customer-facing site, and a staging environment. Write access is not needed at the start: our changes reach your code as pull requests through your normal review.

Can you work alongside our in-house team and other agencies?

Yes. Most corporate sites have several teams in them. We work in your tickets and your review process, and hand over what we learn as written notes, so your own engineers own the result.

Will you sign our NDA and complete our security questionnaire?

Yes to both. The questionnaire is completed as part of scoping, at no cost, and our own practices are published for your team to read first. Security practices

How is the work priced?

Scoped individually. You receive a fixed, written proposal within 3 business days of the first conversation, covering the codebase read and the first sprints, before anything is committed.

Who owns the code?

You do, in full. Every change lands in your repositories under your licence, and nothing we ship leaves a dependency on us.

Send us the page that’s letting customers down.

One address is enough to start. We’ll reply within one business day with what we’d look at first.

Start the brief

Or email support@stacklumen.com

Powered byTerminal