Retail
Software engineering for Ecommerce
In e-commerce, speed and checkout friction are revenue, not vanity metrics. We build online stores that stay fast under load, convert on mobile and survive peak, and we will tell you honestly when Shopify or an off-the-shelf platform is the better business decision than anything we could build for you.
Why the domain matters
E-commerce is software judged by a single, unforgiving number: conversion. Everything else (the catalogue, the merchandising, the design), is in service of turning a visitor into a paying customer, and most of what determines whether that happens is not features. It is speed and friction. A store that takes an extra second to render loses buyers before they see the product; a checkout with one avoidable step abandons carts that were ready to pay. This is the sector where Core Web Vitals are not an SEO abstraction but a line item on the revenue statement, and where the difference between a fast, frictionless flow and a merely adequate one is measured in real money every single day.
The defining decision in online commerce is not how to build, but whether to build at all, and if so, on what. For the large majority of merchants, a bespoke platform is the wrong answer: Shopify, or another off-the-shelf platform, is cheaper to run, faster to launch, and better supported than anything a consultancy can hand-roll, and it frees you to spend on the things that actually move conversion. Custom and headless builds earn their cost only when catalogue complexity, deep customisation, or a front end the platform cannot deliver genuinely justify it. We will say which side of that line you are on before you spend a penny, because getting this decision wrong is the most expensive mistake in the sector.
We are engineers who operate what we build, and in commerce that means we live with the peak. We are the ones watching the dashboards on Black Friday when traffic is ten times a normal day, chasing the checkout error that only appears under load, and reconciling the orders that did and did not make it to fulfilment. That perspective shapes how we work: we care less about the feature list and more about whether the store is fast on a mid-range phone, whether checkout holds together when a payment gateway is slow, and whether the whole thing degrades gracefully when the traffic that pays the year’s bills arrives all at once.
The challenges in ecommerce
Performance is revenue, and it decays quietly
Site speed maps directly to conversion, and the relationship is punishing: buyers abandon slow pages before they engage. Worse, performance rots. A store that launched fast accumulates third-party scripts, unoptimised images, heavy tracking tags and marketing pixels until Core Web Vitals quietly slide and nobody notices the lost sales because there is no error, just fewer orders. Keeping a storefront fast is an ongoing discipline, not a launch-day achievement.
Checkout friction abandons ready-to-buy customers
The checkout is where intent turns into revenue or evaporates, and every avoidable step, forced account creation, surprise cost or clumsy mobile form loses buyers who had their card in hand. Abandonment is rarely a pricing problem; it is usually a friction problem. Getting checkout right (express payment options, guest flows, honest costs shown early, minimal fields), often does more for revenue than any feature on the roadmap.
Peak scale is a different system to the everyday one
Black Friday, a viral moment or a big drop can put ten or twenty times normal load on a store within minutes, and the failure modes that appear only under that load (database contention, oversold inventory, a payment gateway buckling, a cache stampede), do not show up in ordinary testing. The traffic that generates a large share of the year’s revenue is the traffic most likely to break the store, which is precisely backwards unless you design for it deliberately.
The platform decision constrains everything after it
Choosing Shopify, Adobe Commerce or a bespoke/headless build is the decision every other decision inherits. Pick a platform that cannot handle your catalogue complexity and you fight it forever; over-build a custom platform for a catalogue an off-the-shelf tool would have handled and you carry needless cost and operational burden for years. Merchants routinely make this call on brand preference or an agency’s comfort zone rather than on their actual catalogue and customisation needs.
Catalogue, search and merchandising decide what sells
Customers cannot buy what they cannot find. Poor on-site search, weak faceted navigation and flat merchandising bury the products that would have sold, while a large or complex catalogue (variants, configurable products, regional pricing, frequent change), strains platforms that assumed something simpler. The gap between good and poor discovery is a direct gap in revenue, and it is invisible until you measure it.
Payments, fraud and PCI sit on the critical path
The checkout touches money, which means it touches PCI DSS, chargebacks and fraud. Handling card data carelessly drags you into costly compliance scope; handling fraud carelessly bleeds margin through chargebacks and lost stock. Both have to be designed into the payment flow rather than bolted on, and both trade off against conversion. Every anti-fraud check and authentication step is also a point where a genuine customer might give up.
What we build for ecommerce
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Storefronts on the right platform
For most merchants the right answer is a well-built store on an off-the-shelf platform. Most often Shopify for its speed to launch and low operational burden, sometimes Adobe Commerce (Magento) where the catalogue is genuinely complex. We build the theme, the integrations and the checkout experience, tune performance and Core Web Vitals, and keep you out of the bespoke complexity you do not need. This is the honest default behind our e-commerce-development service, and where we start most conversations.
Headless and composable commerce
When the platform’s stock front end cannot deliver the experience or performance you need, a headless build separates the storefront from the commerce engine. A fast, custom front end backed by Shopify, a commerce API or a composable stack. It buys you a better, faster, more distinctive front end at a materially higher build and maintenance cost. We are candid that this is the right choice for some brands and an expensive indulgence for others, and we help you tell which you are.
Marketplace and multi-vendor platforms
Platforms where many sellers list, sell and get paid are a different beast to a single-merchant store: vendor onboarding, split payments and payouts, commission handling, per-seller catalogues and the trust-and-safety machinery that keeps the marketplace honest. These usually justify a bespoke or heavily customised build, because off-the-shelf tools rarely model the multi-sided economics well. We build the platform and the seller-facing tooling that makes it operable.
Checkout and conversion optimisation
Focused work on the part of the funnel where money is won or lost: express and wallet payments, guest checkout, honest early display of shipping and tax, minimal mobile-first forms, and the removal of the small frictions that quietly abandon carts. This is frequently the highest-return engineering you can do in commerce, because it improves revenue on traffic you have already paid to acquire.
Subscription and recurring commerce
Recurring-revenue commerce (replenishment, subscription boxes, memberships), brings problems a one-off store never faces: recurring billing, dunning and failed-payment recovery, plan changes, pausing and skipping, and the churn mechanics that decide whether the model works. We build the billing and lifecycle logic, integrate the recurring-payment provider, and design the customer controls that keep churn down without hiding the cancel button.
Platform migrations and re-platforming
Moving from one platform to another, off a legacy Magento build, onto or off Shopify, from monolith to headless, is high-risk work where the danger is not the new build but the switch: preserving URLs and SEO, migrating catalogue, customer and order history intact, and cutting over without losing traffic or trading days. We plan migrations around not breaking what already works, because a re-platform that tanks organic rankings can cost more than it saves for a year.
Where we help
A store that stays fast on a mid-range phone
Most commerce traffic is mobile, and the device that matters is not a flagship on office wi-fi but a mid-range phone on a patchy connection. We build and tune storefronts against that reality, image optimisation, disciplined third-party scripts, sensible caching and a real Core Web Vitals budget, so the store is fast where your customers actually are, and stays fast as marketing tags accumulate.
A checkout that survives a slow payment gateway
The payment gateway will, at some point, be slow or briefly unavailable, and on a busy day that is exactly when it hurts. We design checkout to handle it gracefully: idempotent order creation so a retried payment cannot double-charge or double-order, clear pending states, and reconciliation against the gateway so every authorised payment maps to exactly one order and no sale silently vanishes.
Peak readiness before Black Friday
Ahead of peak we load-test against realistic traffic, find the component that breaks first, and fix it before customers do. The oversell race on the last unit of stock, the cache stampede when a promo drops, the database query that falls over at ten times load. The goal is that the busiest, most valuable day of the year is boring from an engineering standpoint, because the interesting problems were found in October.
Search and merchandising that surface what sells
We wire in on-site search and faceted navigation that actually find products, and merchandising controls that let your team promote the right stock without a developer in the loop. For a large or complex catalogue that often means a dedicated search service rather than the platform’s built-in query, so that discovery keeps pace with the range you actually sell.
How we build for e-commerce
We start by challenging the build itself. Before any architecture, we ask whether you should be building bespoke at all, and for most merchants the honest answer is no. Shopify or an off-the-shelf platform will be cheaper, faster and better supported than anything we could hand-roll, and we would rather set you up well on one of those than sell you a custom platform you do not need. Only genuine catalogue complexity, deep customisation or a front end the platform cannot deliver moves you across the line to headless or bespoke, and we make that case explicitly, not by default.
We treat performance as a first-class requirement with a real budget, not a nice-to-have. Core Web Vitals go into the brief with target numbers, image and script discipline is designed in from the start, and we push back when a marketing tag or a heavy widget threatens the speed that drives conversion. Because performance decays, we set up the measurement to catch the slide before it costs you sales, rather than discovering it in a quarterly report.
We design the checkout as the most important surface in the product. It gets the mobile-first attention, the express-payment options, the guest flow and the honest early display of costs, and it gets the correctness work, because a checkout that double-charges or drops an order under load destroys trust faster than any slow page. This is where we spend disproportionate care, because it is where revenue is decided.
We build for peak from the outset rather than bolting on scale later. That means understanding where load concentrates, keeping the hot paths cacheable, handling inventory so the last unit is not oversold, and load-testing against realistic peak traffic well before the day. Designing for the everyday and hoping peak holds is how stores fall over on their most profitable day.
Because we operate what we build, we plan for the day the gateway is slow, the third party is down or the traffic is unexpected. Idempotent orders, reconciliation against payment and fulfilment, graceful degradation and alerting that tells us something is wrong before customers do. This is the unglamorous work that separates a store that has a bad afternoon from one that loses a day of trading.
Compliance and consumer protection online
The heaviest compliance weight in commerce sits on payments. Taking card payments brings PCI DSS into play, and the single most important decision is to keep raw card data out of your systems entirely: using the payment provider’s hosted fields or vaulting so that what touches your servers is a token, not a card number. Done right, this keeps your PCI scope minimal and your risk manageable; done carelessly, it is a costly, high-risk liability. This is an engineering decision with direct compliance consequences, which is why we make it early.
Selling to UK and EU consumers means consumer-protection law reaches into the software: clear pricing with no hidden costs sprung at checkout, the cancellation and returns rights consumers are entitled to, and honest presentation of what is being sold. Much of this is your legal and commercial responsibility, but the store has to implement it faithfully: the returns flow, the pricing display and the terms have to match what the law and your policy actually promise.
Data-protection law (UK GDPR and PECR), governs customer accounts, marketing consent and the cookies and tracking that commerce sites lean on heavily. Marketing consent, analytics and advertising pixels all have to be handled lawfully, and the consent mechanics have to genuinely control what fires, not merely appear to. This intersects with performance too, because the tracking stack that raises compliance questions is often the same stack that slows the store down.
To be clear about the boundary: we are your engineering partner, not your lawyers or your compliance advisers. We build the store to implement the pricing, returns, consent and data-handling obligations your legal advisers define, and we keep your payment architecture out of unnecessary PCI scope. Confirming exactly what your specific obligations are, and that a given design meets them, is work for people qualified to give that advice, and we will build to their requirements rather than improvise our own.
The e-commerce integration stack
Payment gateways sit on the critical path, and integrating them well is about far more than taking a card. It means idempotent order creation so a retry cannot double-charge, robust webhook handling for asynchronous payment confirmation that can arrive late or out of order, support for the express and wallet payments that lift conversion, and reconciliation so every captured payment maps to exactly one order. When the gateway is slow on a busy day, the quality of this integration decides whether you lose sales or ride it out.
ERP and inventory systems are the source of truth for stock and pricing, and keeping the storefront in sync with them is a perennial source of trouble. Overselling because inventory lagged, mispricing because a feed was stale, orders that do not flow cleanly into the back office: these are integration failures, and we treat the sync between store and ERP as a reliability problem to be engineered, not a nightly export to be hoped over.
Fulfilment and 3PL integration is where an order becomes a parcel. Pushing orders to a warehouse or third-party logistics provider, pulling back tracking and delivery status, and handling the exceptions (a split shipment, a stockout at the warehouse, a failed delivery), is what determines whether the post-purchase experience holds up. Returns run through here too, and a smooth returns flow is both a consumer-protection obligation and a genuine driver of repeat custom.
Marketing and analytics tooling (analytics, tag management, email and CRM, advertising pixels and conversion tracking), is essential to running a commercial store, and also the most common cause of performance and consent problems. We integrate this stack deliberately, keeping it lawful under consent rules and disciplined about the performance cost, rather than letting tags accumulate until Core Web Vitals and page speed quietly degrade.
Marketplaces (selling through Amazon, eBay and comparison channels alongside your own store), bring multi-channel inventory and order management into scope, so that stock, pricing and orders stay consistent across every channel you sell on. For platforms that are themselves marketplaces, the integration problem inverts into vendor onboarding, split payouts and per-seller catalogues, which is a substantially larger build.
Security for online commerce
Commerce stores are attacked constantly, because they combine two things attackers want: money moving through checkout and a database of customer and order data. The threat is broad: card and payment fraud, account takeover through credential stuffing, card testing against your checkout, bot-driven scalping and abuse, and attempts to reach the customer data you hold. Security here is a design constraint from the first commit, present in the checkout, the authentication and the way customer data is handled, not a hardening pass before launch.
The most important card-security decision is not to hold card data at all. We architect payments so that primary account numbers are captured and vaulted by your payment provider and never touch your systems, keeping you in the smallest possible PCI DSS scope. You cannot leak what you never stored, and staying out of scope is almost always both safer and cheaper than trying to secure card data yourself.
Customer data (accounts, addresses, order history, saved payment tokens), has to be protected in its own right. That means encryption in transit and at rest, disciplined access control, data minimisation so you hold only what you need, and treating the customer database as the sensitive asset it is. A breach of customer data is a breach of trust and a regulatory event, quite apart from any card exposure.
Fraud and abuse controls have to defend the checkout without strangling conversion, which is a genuine balancing act: every fraud check, address verification and authentication step is also a point where a legitimate customer might abandon. We wire in the fraud tooling, rate-limit and challenge the automated abuse (card testing, credential stuffing, scalping bots), and tune the friction so it lands on the risky traffic rather than on everyone.
Around all of this sits the operational security we rely on ourselves because we run the store: least-privilege access, keeping the platform and its plugins patched (a major source of commerce breaches, especially on self-hosted stacks), tamper-evident logging, and a rehearsed answer for when something goes wrong during peak. Because we operate what we build, these are not documents we hand over. They are the controls standing between a busy day and a bad one.
What changes
A store that converts because it is fast
A storefront that meets a real Core Web Vitals budget and stays fast on the mid-range mobile devices your customers actually use, so you stop losing buyers to slow pages, and stop leaking the revenue that speed quietly costs when nobody is watching the numbers.
Checkout and orders that hold under load
A checkout that is frictionless when it works and correct when the gateway is slow, idempotent, reconciled, and free of the double-charges and dropped orders that destroy trust. The busiest day of the year becomes an engineering non-event instead of an annual crisis.
The right platform decision, honestly made
A clear-eyed choice between an off-the-shelf platform, headless and bespoke, matched to your actual catalogue and customisation needs rather than to fashion, usually meaning you spend on what moves conversion and avoid the cost of custom complexity you never needed.
What we build for ecommerce
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for ecommerce?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in ecommerce choose us
We will talk you out of building bespoke
Most merchants should be on Shopify or an off-the-shelf platform, and we say so, even when it means a smaller engagement for us. We would rather set you up well on the right platform than sell you a custom build that costs more, launches slower and needs more looking after than the business justifies.
Senior engineers who have watched the peak dashboards
Our people are senior engineers who have run stores through Black Friday, chased the checkout error that only shows under load, and reconciled the orders that nearly went missing. That operational scar tissue is why we design for peak and failure from the start, not after the first bad day.
We treat performance and checkout as revenue, not polish
We optimise the two things that actually move the number (speed and checkout friction), before we chase features, because that is where conversion is won on traffic you have already paid to acquire. We bring a real performance budget and a mobile-first checkout to the brief, not as an afterthought.
We operate what we build
We do not hand over a store and disappear before the first peak. Living with the load, the gateway wobbles and the reconciliation is exactly why we take the unglamorous correctness, observability and scale work seriously, because we are the ones on the dashboard when it matters.
Related sectors
Part of Retail. Adjacent sectors we also know.
Common questions
Should we build a custom store or use Shopify?
For most merchants, Shopify or another off-the-shelf platform is the better business decision, and we will tell you so plainly. It is cheaper to run, faster to launch and better supported than anything we could build for you, and it lets you spend on the things that actually move conversion. A bespoke or headless build only earns its cost when your catalogue complexity, customisation needs or front-end requirements genuinely exceed what an off-the-shelf platform can deliver. We help you work out which side of that line you are on before you commit, because getting this decision wrong is the most expensive mistake in the sector.
What is headless commerce, and do we need it?
Headless commerce separates the storefront (the front end customers see), from the commerce engine behind it, so you can build a fast, custom front end backed by Shopify, a commerce API or a composable stack. It buys you a better, faster and more distinctive front end at a materially higher build and ongoing maintenance cost. It is the right choice for some brands and an expensive indulgence for others. Unless the platform’s stock front end genuinely cannot deliver the experience or performance you need, you probably do not need it, and we would rather save you the cost than sell you the complexity.
Why does site speed matter so much for an online store?
Because speed is conversion, and conversion is revenue. Buyers abandon slow pages before they engage, and the effect compounds on mobile, where most commerce traffic now sits. Core Web Vitals are not just an SEO signal in commerce; they map directly to how many visitors become customers. Performance also decays quietly as marketing tags, tracking scripts and unoptimised images accumulate, so there is usually no error to alert you, just fewer orders than there should be. We treat performance as a first-class requirement with a real budget and ongoing measurement, precisely because the cost of ignoring it is invisible until you look for it.
How do you prepare a store for Black Friday and peak traffic?
We treat peak as a different system to the everyday one, because the failure modes that appear at ten or twenty times normal load (database contention, oversold inventory, a payment gateway buckling, a cache stampede), do not show up in ordinary testing. Ahead of peak we load-test against realistic traffic, find the component that breaks first and fix it before customers do, keep the hot paths cacheable, and handle inventory so the last unit is not oversold. The aim is that the busiest, most valuable day of the year is boring from an engineering standpoint, because the interesting problems were found weeks earlier.
Can you migrate us to a new platform without losing our SEO?
Yes, and protecting your existing SEO is the part of a migration we plan around most carefully, because a re-platform that tanks organic rankings can cost more than it saves for a year. The risk in a migration is rarely the new build; it is the cutover: preserving URLs and redirects, migrating catalogue, customer and order history intact, and switching over without losing traffic or trading days. We plan migrations around not breaking what already works and ranks, rather than treating the old store as something to be discarded, so the move is a step forward rather than a self-inflicted setback.
Building for ecommerce?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if ecommerce is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.