Ecommerce projects rarely get hard because of the storefront. They get hard when the storefront has to meet the needs of the rest of the business.
Inventory already lives somewhere. Orders land somewhere else. Finance has its own systems. Payments drag security and compliance into scope. And the platform picked in month one defines what's easy, expensive, or impossible two years later.
Which is why the first question shouldn't be Shopify vs Magento vs WooCommerce vs custom. Starting there means arguing about features before anyone understands the constraints. The better opening question: what are we actually building, and which parts genuinely need to be custom?
For most people reading this, the honest answer is buy a platform and move on.
The phase ordering that costs the most
Seven phases: discovery, architecture and platform selection, design, build and integration, data migration, compliance and security review, launch and first optimization. Four to seven months for a mid-market build.
The sequence matters more than the labels, and one inversion is expensive above all others: choosing a platform before you've scoped compliance. Do it in that order and a compliance finding can force a re-architecture eight weeks into the build.
Two phases account for most overruns:
- Build slips because discovery missed a system. The integration nobody scoped in phase 1 surfaces two months late, when the schedule has no slack left. Discovery in commerce isn't about pages — it's about finding every system holding a number the store needs, and finding who can grant access to it. That list is always longer than the brief.
- Compliance review slips because it was treated as a formality. Remediation lands on a team that has already released its engineers.
Both are schedule problems created long before they appear.
Staffing note worth agreeing in writing before kickoff: phases 1, 2, and 6 need someone on the client side — a person who can get you into the ERP, whoever signs the contract, and named owners for the payment page and accessibility. Phases 3, 4, and 5 can sit almost entirely with the build team. The three phases you have to staff are the three that stall when nobody's free.
Three dates that already passed
These are no longer planning questions. They're evidence questions.
- PCI DSS v4.0.1 req 6.4.3 and 11.6.1, in force since 2025-03-31. Inventory every script on the payment page, authorize each one, justify why it's there, and detect unauthorized changes to page headers and content. The catch: the scripts in question are usually marketing tags nobody in engineering added. PCI now has an owner problem — the tag manager on checkout needs a named owner and an approval step.
- European Accessibility Act, Art. 2(2)(f), applying after 2025-06-28 to ecommerce services sold to EU consumers. Measured against EN 301 549, which points at WCAG. "We'll do accessibility after launch" is now a statement about legal exposure, not backlog priority.
- GDPR / CCPA / CPRA, unchanged but load-bearing. Consent, access, and deletion paths wired into the customer data model rather than bolted on. If a deletion request can't be executed against the customer record without an engineer, it doesn't scale past the first hundred.
Accessibility written as an acceptance criterion in phase 3 costs days. Discovered in phase 6, it costs weeks. Same work, different bill.
Checkout: the causes are business decisions, not design problems
The average documented cart abandonment rate is 70.22% (Baymard, across 50 studies, updated 2025-09-22). Among shoppers who intended to buy, the top causes:
- Extra costs shown too late — shipping, tax, fees — at 40%.
- Slow delivery, 20%.
- Distrust of the payment form, 19%.
- Forced account creation, 18%.
Three of those four are decisions no redesign can make on your behalf. In order of what actually abandons carts: show the full total on the cart page, offer guest checkout, give a real delivery date rather than a shipping-method name, make the payment step look like a payment step, and cut every optional field.
Run A/B tests only after those five are in place. Below a few thousand checkouts a month you don't have the traffic to detect a one-point conversion change without weeks per variant, and teams routinely call the result on day four because the chart looks decided. Testing earns its place above the checkout — category layouts, product page structure, price and delivery presentation — where there's more traffic per decision.
Where AI actually earns its place
The test: does the model's output change a decision somebody was already making on worse information?
- Demand forecasting and replenishment. Output is a purchase order quantity. Error is countable against what sold.
- Fraud and chargeback scoring. Output is a score with a threshold. Both false positives and false negatives show up in the finance report — which means the review interface is in scope, not a follow-up.
- Search and merchandising, but above roughly ten thousand SKUs, where manual merchandising already stopped covering the tail.
Where it doesn't: personalization on a 200-SKU catalog has too little behaviour to learn from and the engineering cost lands anyway. Dynamic pricing on consumer goods invites a customer to screenshot two prices and post them. Generated product copy at scale reads like generated product copy at scale, on exactly the pages you wanted indexed.
Separately — AI in the build is a different question from AI in the store. Coding assistants compress phases 3 and 4. They don't touch 1, 5, or 6, which is where the schedule risk lives, because those are constrained by other people's systems and by evidence someone has to sign.
Composable, honestly
Headless decouples the front end and is a configuration option on several hosted platforms. Composable replaces the engine with separate services. Headless is a weekend of architecture; composable is a program of work. The terms get used interchangeably and shouldn't be.
On a composable build, expect the first feature to take four to six weeks longer than on a coupled platform, and expect payback to start around the third. If your roadmap has three changes in it, the arithmetic doesn't work.
You also inherit a service layer somebody maintains, and six services that fail in more ways than one platform does. "Wanting to be modern" is not a reason. Multi-channel selling from one inventory, or business rules no vendor has productized, are.
If the reason is real, migrate incrementally: routing layer in front of the existing store, move one capability behind it, run both, move the next. Search and product content first — read-heavy, low-risk. Checkout near the end, because it handles the money and the compliance scope. Teams that move checkout first take the program's largest risk before learning anything.
The three-year number
Build cost is the number in the quote and the smaller half of the decision. A $70,000 build with $12,000 annual maintenance and $1,500 a month in platform fees is a $160,000 commitment before a single new feature ships.
Price every platform over three years, because the fee structures behave differently: revenue-percentage platforms get more expensive as you succeed, self-hosted charges you in engineering hours whether you grow or not, licence-plus-build front-loads and holds steady. Ask each vendor what the bill looks like at three times current volume, and get it in writing. That belongs in phase 2, not the post-launch review.
And then the question underneath all of it. Under roughly $5M in annual online revenue, with a standard catalog and standard checkout, buying wins on price, time, and risk. Custom development is the answer to a named business rule you can attach a cost to living without — never to a general preference for control.
Full breakdown — all seven phases, the platform comparison table, and the build-vs-buy signals: see the full guide
Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.
Top comments (0)