Contents
01Why two quotes for the same store differ tenfold
Because the words describe different projects. A store with twenty products, flat shipping and a single payment method is a configuration job. The same twenty products with size and colour variants, state tax rules, freight for large items, a wholesale price list and an inventory sync to an existing system is a software project that happens to have a shop on the front.
Ask any quote which of those it assumed. A number without that answer is a guess, and the gap shows up later as change requests.
02The four things that move the number
In the projects we scope, these four account for nearly all the difference.
- The catalog: variants, options, bundles, products priced by dimension or weight, and whether the data exists anywhere in clean form yet.
- Shipping and tax: flat rates are simple, carrier rates by weight and zone are not, and freight items with delivery appointments are their own project.
- Who else needs to know about the order: accounting, a warehouse, a supplier, a point of sale system in a physical store.
- How customers buy: guest checkout only, accounts with order history, subscriptions, wholesale tiers, quotes before purchase.
Catalog data is the most underestimated line in every ecommerce project. Cleaning and structuring it is often the longest single task.
03Platform or custom
Use a hosted platform unless you have a specific reason not to. You are renting payment compliance, fraud screening, uptime, tax tables and a checkout that millions of people have already used without confusion. Rebuilding that is expensive and the result is almost never better at the thing that matters, which is getting a card charged without friction.
Custom becomes the honest answer when the way you sell does not fit a cart: configurable products priced from a formula, quotes that turn into orders, contract pricing per customer, or a store that is really a front end on an internal system. We build those, and we also talk clients out of them when a platform with an app would do.
04The costs that arrive after launch
Plan for them in the first budget, because they decide whether the store is profitable at your volume. Platform subscription, payment processing on every order, the apps you added for reviews and shipping labels, product photography as the range changes, and the hours someone spends keeping it current.
Processing is the one people forget to model. At a few percent of every order it is a real line in the unit economics, and the difference between providers matters more as volume grows. Work it out at your expected volume rather than at launch volume.
05Speed and the checkout are where revenue leaks
Two technical things pay for themselves on an ecommerce site. The first is speed on a phone, because you pay for the visitor whether or not the page finished loading. The second is a checkout with no surprises: shipping cost visible before the final step, no forced account creation, and a form that works with autofill.
We have written separately about what a slow site costs and how to find the lost seconds. For a store the same work has a shorter payback, because the traffic is usually bought.
06How we scope it
Discovery is fixed price at $2,400 over three working days: the catalog structure, the shipping and tax rules, the integrations, the checkout decisions and a price band with the factors that move it. Build starts at $12,000 and you own the store and every account from the first day.
If discovery concludes that a platform with two apps and a week of configuration solves your case, that is in the document too, and you keep it either way.
Questions
Can we start small and add to it?
Yes, and that is usually the right order: launch with the products that sell, flat shipping and one payment method, then add rules once real orders show you which ones you need. The exception is inventory sync, which is cheaper to design in than to retrofit.
Who writes the product descriptions and takes the photos?
You or a specialist, and it is worth planning early because it is the common reason launches slip. The build does not depend on it, but the launch does: a store with placeholder content is not a store you can advertise.
Will the store be editable by our team?
Yes. Products, prices, pages and promotions are edited by your staff without us. That is a requirement we design for rather than a feature we add at the end, because a store nobody on your side can change goes stale within a quarter.
Where we can help