A common first question from store owners is what a project costs on Shopify compared with Adobe Commerce. It is a reasonable question with a disappointing answer: the platform is rarely what decides the bill. We compared the licences in what Adobe Commerce, Shopify and BigCommerce actually cost, and even there the licence was usually the smallest number in the total.
What decides the bill is the set of problems the store already has, most of which sit outside the storefront. That is why we won't quote a figure on the first call, and why the quote we do write is split into phases, each with its assumptions written down.
Why a price list can't answer the question
Two stores on the same platform, with the same number of products, can need very different projects. One keeps its stock in Shopify and ships from one warehouse. The other has stock mastered in an ERP, a courier with its own API, a finance team that needs every invoice to match, and a marketplace feed with its own format. The storefront work is similar. Everything around it isn't.
So our honest answer to "what does it cost" is the shape rather than a number: an integration or a focused piece of work is usually measured in weeks, a platform build in months. What moves a project from one end of that range to the other is what the rest of this piece is about.
For a sense of scale: a first integration phase usually lands between 1 and 3 weeks.
The problems that actually move the number
Two systems that both think they own the truth. Most integration bugs are not code failures. They are two systems both believing they own the price, or the stock level, or the customer record. Until someone decides which system is the record for each field, every connector built on top inherits the argument. Deciding it costs a workshop. Not deciding it costs a campaign weekend of oversold products.
Stock that lives somewhere else. If inventory is mastered in an ERP or a warehouse system, the store only knows what the last sync told it. Whether that sync needs to be near real time or can run nightly is a business decision, and it is worth making per data type: stock usually needs to be fresh because being wrong means an oversell, while financial postings are often fine overnight. Making everything real time "to be safe" is one of the quietest ways to inflate a budget.
Product data nobody has cleaned. Catalogues accumulate attributes in the wrong places: sizes in tags, materials in titles, variants split into separate products. Every migration, search project or AI channel has to deal with it. It also costs sales directly: Baymard's usability research found that 10% of the largest e-commerce sites don't keep a consistently high level of detail in their product descriptions, and test users abandoned products when they couldn't find what they needed. Cleaning data is unglamorous work that no platform does for you.
Business rules that don't fit a cart. Rentals with availability windows, marketplaces with per-vendor payouts, configurators where the price depends on a dozen inputs. These bend a platform until the workarounds cost more than building the part that is genuinely yours. The test we use is simple: list the five things a platform would force you to work around. If they are cosmetic or only affect the admin, stay on the platform. If they touch how money is calculated, how inventory behaves over time or who is party to a transaction, it is time to look at custom.
Integrations someone else built. Fixing those is a good share of what we do. We start by instrumenting the connector to find where records actually go missing, which is frequently somewhere other than where the team suspects, and the fix is sometimes small. Sometimes the honest answer is that a rewrite is cheaper than another patch. Either way, you can't price it before you look.
One example from our own work: a client came to us for a redesign. Discovery showed that half their product attributes lived in tags and titles, and cleaning the catalogue took longer than the theme work, close to two months.
How we turn problems into a quote
Discovery first, when it isn't obvious. A short discovery maps the systems, the constraints and what is genuinely in the way, and ends with a written recommendation. Sometimes that recommendation is that you don't need a build at all, which is a cheaper answer than finding out six months in.
Phases, with the assumptions written down. We quote per phase so you can see what moves the number before you commit to the whole thing. If an assumption turns out to be wrong, it is visible which part of the price it affects.
Fixed price where the scope is precise. A migration, a connector or a defined feature set can be fixed-priced. Ongoing product work is better on a monthly team, because pretending an evolving roadmap can be fixed-priced usually ends in an argument about what was in scope.
Start with something small. A first phase that ships something real tells you more about working with us than any reference call, and it tells us more about your systems than any discovery document.
What makes the same project cheaper
A few decisions reliably take cost out before any code is written:
- Pick one system of record per field and write it down.
- Decide batch or real time per flow, not globally.
- Build the risky part first. Whatever is most likely to be wrong, the pricing engine, the availability calendar, the payout maths, gets built and tested against real data early.
- Look for the platform-shaped answer before the custom one. If Shopify, BigCommerce, Adobe Commerce or Medusa can carry the model with reasonable extension, that is the cheaper project.
What to bring to the first call
You don't need a specification. These five things are enough to turn a conversation into an estimate:
- The list of systems around the store: ERP, warehouse, PIM, couriers, marketplaces, finance.
- Which system is the truth for stock and price today, even if the answer is "it depends".
- Three things that currently go wrong, in the words the operations team uses.
- The rules that make your business unusual: how price is derived, how availability works, who gets paid what.
- What a good first phase would change for you, in one sentence.
If you would rather work through your own list with us, talk to us.
Product data figures from Baymard Institute's research on product descriptions. Zelpex's approach as described on our custom e-commerce and integration pages and in our FAQ.
Have a project like this on your desk?
Send us a few lines about where things stand. We will read it, tell you what we would look at first, and whether we are the right people for it.
Talk to us about your case