E-commerce engineering
Most e-commerce problems we are called about are infrastructure problems wearing a marketing costume. Conversion is down, so the agency is asked to change the button. The button is not the problem. The problem is that the product page takes four seconds on a phone on a mobile network, and a third of the people who tapped the ad never saw it.
We work on the engineering underneath a store: performance, checkout reliability, catalogue and inventory accuracy, and the infrastructure that has to hold on the day the campaign works.
Where the money leaks
Speed
On a phone, on a real network, not a lab score.
Checkout
The failures nobody reports, because the customer simply leaves.
Stock
Wrong stock costs the sale twice: once now, once in trust.
Peak load
The day the campaign works is the day it must hold.
Speed, on a phone, on a real network
Store performance is usually measured on a developer’s laptop on office fibre. Your customers are on a phone, on cellular, often with a mid range Android device doing the work. The difference is not subtle: the same page can be under a second in one case and five in the other.
The wins are almost always the same and almost always unglamorous. Images that are the right size and format, which is usually the single biggest one. Third party scripts, which are usually the second: a typical store loads analytics, a chat widget, two pixels, a review service and a personalisation tool, each of which was added by someone who did not know about the others. Then caching and query design.
We measure before and after on throttled mobile, because a number from a laptop is not a number.
Checkout that fails quietly
Checkout is where every external dependency you have shows up at once: payment provider, address validation, shipping rates, tax, fraud scoring. Each one is a chance to lose a customer who had already decided to buy.
The fix is the same discipline as any integration. Anything that can be done after the order is confirmed happens after the order is confirmed. Anything that genuinely must be synchronous gets a timeout and a defined fallback. A shipping rate service being slow should degrade to a flat rate, not to a spinner.
Stock that is wrong
Overselling costs you the order, the refund, the support conversation and the customer. Underselling just costs you the order, quietly, forever. Both come from the same place: nobody decided which system owns the number and how fresh the copy is allowed to be.
We make that explicit, and where the traffic justifies it we move stock to event driven updates instead of a scheduled sync that is wrong for fourteen minutes out of every fifteen.
The day the campaign works
Traffic spikes are a good problem that arrives looking like a bad one. Most stores fall over on a spike not because the servers are too small but because one uncached query runs per visitor, or the image resizer is doing work it should have done once. We load test against your actual peak shape before the campaign, not after.
What we do not do
We are not a marketing agency. We do not run your ads, write your product copy or manage your channels, and if your conversion problem is genuinely a merchandising problem we will say so and tell you that we are the wrong supplier for it.
We also work happily alongside the agency that does own those things, which is a common arrangement: they hold the client relationship and the commercial strategy, we make the machine underneath fast and reliable.
Platforms
We work with stores on the common platforms as well as custom builds. Our bias is to keep a platform that is working and fix what is actually slow, rather than propose a replatform, which is the most expensive way to solve a caching problem.
Where a business genuinely has outgrown its platform, usually because its pricing, bundling or fulfilment rules cannot be expressed in it, that is a custom platform conversation and we will tell you plainly which of the two you are in.
How the work runs
Almost every e-commerce engagement starts with a measured audit: real device performance, checkout failure rates, where the queries and the third party scripts are going, and what the infrastructure actually costs. That produces a ranked list with expected impact, and the first items are usually cheap.
We then work in short cycles, measuring each change, because e-commerce is one of the few places where the effect of engineering work can be seen directly in a number the business already watches.
Related
Store work almost always involves system integration with an ERP or a warehouse system, and the front end itself is web development. Where the business rules have outgrown the platform, see custom software platforms.
Common questions
How much faster can you realistically make our store?
On a store that has never had performance work, halving mobile load time is a normal result and the first tranche of it usually comes from images and third party scripts. We will not quote a number for your store before measuring it, and we will tell you if there is little left to win.
Do we have to replatform?
Usually not, and we will argue against it unless your business rules genuinely cannot be expressed in what you have. Replatforming to fix speed is an expensive way to solve a problem that is usually about images, scripts and caching.
Can you work with our marketing agency?
Yes, and it is a common arrangement. They own the storefront and the campaigns, we own the engineering underneath. We are used to being the supplier that is not client facing.
What about the busiest day of the year?
We load test against your real peak shape beforehand and agree what degrades gracefully if the peak is bigger than planned. Deciding in advance that a recommendation widget can disappear is much better than discovering during the peak that it takes checkout with it.
Will this break our tracking?
No, and we check. Analytics and pixels are usually the heaviest thing on the page, so the work often involves changing how they load rather than whether they do. We verify that events still fire before and after, because a faster store with broken attribution is not a win.
More services
Next
Tell us what you are building, or what is breaking.