Start at the checkout and work backwards
Most e-commerce projects begin with the homepage, because that is the page everybody has an opinion about. It is the wrong place to start. The homepage is where people arrive; the checkout is where the business either happens or does not.
So we work in reverse. What is the minimum number of steps between wanting the product and having bought it? What information does someone need at each step to not hesitate, shipping cost, delivery date, return policy, whether the thing is actually in stock? Every one of those questions, unanswered at the wrong moment, is an exit.
The unglamorous things move the number.Guest checkout that actually works. Address fields that do not reject valid postcodes. Payment methods people in your market recognise. Error messages that say what went wrong instead of “an error occurred”. None of it will win a design award. All of it shows up in revenue.
Shopify
For the majority of stores, Shopify is simply the correct answer, and we will say so even though a custom build would bill more. Hosting, PCI compliance, payment infrastructure and platform security are handled, which means the budget goes into the parts that differentiate you.
Where Shopify builds go wrong is app sprawl. Every app you install injects its own JavaScript into every page. We have opened stores carrying a dozen apps where half were doing something the theme could have done natively at no performance cost. Part of a Shopify engagement is auditing that and removing what is not earning its weight.
WooCommerce
WooCommerce earns its place when content and commerce are genuinely intertwined, a brand whose blog, guides and comparison content do real acquisition work, and whose products need to sit inside that ecosystem rather than beside it.
It also means no per-transaction platform fee and complete ownership of your data. The trade-off is that hosting, security and performance become your responsibility. Built well and maintained properly, it is excellent. Built on a bought theme with thirty plugins and left un-updated, it becomes the single most common security incident we get called in to clean up.
Magento and Adobe Commerce
Magento is for complexity that would break a simpler platform: customer-specific B2B pricing, multi-warehouse inventory, thousands of SKUs with real attribute depth, multi-store setups under one back end.
It is also demanding to run and expensive to host. If your catalogue is a few hundred products with one price each, Magento is an expensive way to solve a problem you do not have, and we will tell you that rather than take the larger project.
Custom and headless builds
A headless build puts a React or Next.js front end over a commerce backend. The storefront becomes about as fast as a storefront can be, and you gain complete freedom over the interface.
The cost is real: you are now maintaining a front end as well as a store, and things the platform gave you free, checkout flows, theme updates, app compatibility, become your problem. It is the right call when speed is a genuine differentiator or the shopping experience itself needs to be unusual. It is the wrong call because someone read that headless is modern.
Complicated catalogues
Some catalogues are hostile by nature, and they need decisions made early:
- Auto parts and fitment data. Nobody browses for a brake pad. They need to know it fits their vehicle. The vehicle-lookup logic is the store; everything else is packaging around it.
- Grocery and perishables. Delivery windows, substitutions, stock that changes hourly. The hard problems are operational and the site has to reflect them honestly rather than promise what the warehouse cannot do.
- B2B with negotiated pricing. Customer-specific price lists, approval workflows, purchase orders, credit terms. This is where a simple platform quietly stops being enough.
- Configurable products. When a product has genuine option logic, where choosing one thing eliminates another, the configurator needs designing as a product in its own right.
What it costs, honestly
We publish no price list, because a store with two integrations and a store with twelve are not the same project, and pretending otherwise would just mean quoting high to cover ourselves.
What we can tell you is what actually drives the number, in order: how many systems the store has to talk to (ERP, inventory, accounting, shipping, CRM), how strange your pricing rules are, whether you are migrating and how much of the old catalogue needs to survive, and only then how custom the design is. Most people assume design is the driver. It is usually fourth.
Send us the store and the list of systems it needs to talk to, and you will get a real number with the reasoning attached.