We build and rebuild storefronts for brands whose current site is costing them orders. Most of that work is unglamorous — the checkout, the search, the product page, the admin your team actually lives in.
thewaterbottlestore.co.uk
Hover to scroll
Hover to scroll
The Water Bottle Store — a multi-brand Shopify storefront built for the UK market. Read the case study
Diagnosis first
Four briefs wearing the same coat
Most enquiries arrive as "we need a new website". Underneath it is nearly always one of these, and they are not the same project.
The checkout is losing orders
Usually fixable where you are. Payment methods, address validation, shipping logic and the three steps nobody tested on a phone.
Nothing ships without a developer
A build problem, not a platform one. Sectioned templates and editable blocks hand the day-to-day back to your merchandisers.
Platform choice is mostly determined by four things, and rarely by preference.
Catalogue complexity. Variant counts, configurable products, bundles and how often the catalogue changes. Adobe Commerce handles deep configurability natively that needs building on Shopify.
How you sell to businesses. Company accounts, contract pricing, quotes, purchase orders, credit terms and approval workflows. Shopify Plus covers a good deal of this now; Adobe Commerce B2B covers more; some of it always needs building.
What is already in your estate. If your service and marketing teams live in Salesforce, Salesforce Commerce Cloud removes integration work that would otherwise be a project in itself. If your ERP has one supported connector, that matters more than any feature comparison.
Who maintains it. A platform your team cannot operate is a platform you will pay an agency to operate forever. This is the factor most often left out of the decision and the one that dominates the three-year cost.
If a React storefront on Shopify’s own stack is on the table, read Hydrogen and Oxygen first — that page is as much about when not to.
What slows builds down
In our experience the front end is almost never the critical path. The things that actually extend timelines are product data that is inconsistent across systems, an ERP integration with no sandbox, tax and duty rules for markets nobody mentioned at kickoff, and discount logic that exists only in someone’s head.
We front-load those in the architecture phase for a reason: finding them in week fourteen is what turns a sixteen-week build into a thirty-week one.
A storefront is only as good as the systems behind it. Most of the risk in a build sits here, not in the front end.
Systems you already run
Payment gateways, ERP, PIM, WMS, CRM, tax engines and marketing platforms — connected to the storefront rather than re-keyed into it.
APIs built to be operated
Typed contracts, idempotent writes, retries and dead-letter handling. Failure modes designed up front, because integrations fail on a Friday night, not in a demo.
Automation where it pays
Order routing, stock sync, returns and customer tagging. We automate the steps your team repeats daily, not the ones that merely look impressive.
One version of the truth
Product and inventory data reconciled across systems, with a defined source of truth per field. Mismatched catalogues are the most common cause of a build overrunning.
Before quoting a rebuild we check whether one is warranted. Search, product pages, checkout friction and post-purchase flows are usually where recoverable revenue sits — and they are a far cheaper place to find it than a replatform.
Sections, blocks and templates your merchandisers can change without a developer. The most expensive stores to run are the ones where every banner is a ticket.
A checkout you have not slowed down
Payment, tax and shipping configured against the platform's native checkout rather than around it. Custom checkout work is a Shopify Plus or SFCC decision, not a default.
Catalogue and merchandising structure
Collections, facets, variant logic and search tuned to how your customers actually browse — which is rarely how the catalogue is organised internally.
Integrations that survive your ERP
Orders, inventory, customers and fulfilment wired to the systems you already run, with retries and error states designed rather than discovered in production.
B2B mechanics where you need them
Company accounts, price lists, quote flows, purchase-order terms and approval chains. Native on Plus and Adobe B2B; built deliberately where it is not.
A performance budget, not a performance promise
Core Web Vitals targets agreed before the build, measured on your real catalogue and your real third-party scripts, not on an empty theme.
How it runs
From first call to live.
Platform decision1–2 weeks
We look at your catalogue size, B2B requirements, ERP, tax footprint and team. Sometimes the answer is that your current platform is fine and the problem is the theme. We will say so.
Architecture and scope2–3 weeks
Data model, integration contracts, template inventory and the performance budget. This is where we find the surprises — the custom ERP field, the legacy discount logic, the 40,000 redirects.
Build8–16 weeks
Templates and integrations in parallel, against a staging environment with real catalogue data. Fortnightly demos on the actual site rather than slides.
Launch1–2 weeks
Redirect map, DNS cutover, analytics parity check and a rollback plan. We watch the numbers for the first week, because the first week is when migrations lose traffic.
AfterOngoing
Support retainer or handover to your team, including the documentation. Either is fine; being vague about which is not.
Frequently asked questions
How long does an enterprise storefront build take?
Twelve to twenty weeks end to end for most D2C builds, including the platform decision and launch. B2B builds with company accounts, contract pricing and ERP integration usually run twenty to thirty. The variable is almost never the front end — it is integration scope and how clean the product data is.
Which platform should we build on?
Shopify Plus for most D2C and a good deal of B2B, because the total cost of ownership is lower and the checkout converts. Adobe Commerce where you need deep B2B rules, complex pricing or self-hosting. Salesforce Commerce Cloud where you are already in the Salesforce estate and want commerce beside Service and Marketing Cloud. We make that call during the platform decision phase, on your constraints rather than our preference.
Do we need headless?
Usually not. Headless — Hydrogen and Oxygen on Shopify — is worth it when you need frontend freedom Liquid genuinely cannot give you, or you are serving several brands and regions from one codebase. It costs more to build and more to run. If a themed storefront will do the job, we will build a themed storefront.
Can you work with our existing agency or in-house team?
Yes, and it is common. We often take the platform and integration work while an in-house team keeps design and merchandising. What matters is that the boundary is written down — who owns which templates, who deploys, who is on call.
What happens to our SEO when we rebuild?
It is protected by the redirect map, which we build from your actual top URLs and crawl data rather than from a sitemap, and by keeping URL structure wherever there is no reason to change it. Expect a short dip in the first fortnight. If you see a sustained drop after that, something was missed, and we fix it.
Do you offer support after launch?
Yes — a monthly retainer covering platform updates, bug fixes, performance monitoring and a block of development hours. The alternative is a documented handover to your own team. We will recommend whichever genuinely fits how you are staffed.
Want to talk through eCommerce Development for your store?
Tell us where it hurts. We will tell you honestly whether we are the right
people for it.
We use analytics cookies (Google Analytics and Microsoft Clarity) to understand how the site is used. Choose whether to allow them;
you can change this any time from Cookie settings. We do not use advertising cookies.
Privacy Policy
