Ecommerce App Development Cost: Two Tiers, and Which One You Are Actually Buying
There are two prices for an ecommerce build and most quotes conflate them.
A D2C launch or a single-channel B2B portal is 700 to 1,400 hours, which at a $60 to $70 blended rate is roughly $42,000 to $98,000. A mid-market omnichannel build — web, POS, one ERP, click and collect and returns — is 1,800 to 3,500 hours, roughly $108,000 to $245,000.
The gap between them is not features. It is the number of places that disagree about what you have in stock. One sales channel has one answer. Four channels and a warehouse have four answers and a reconciliation problem, and that problem is most of the second number.
The question that sets your tier is not "what should the app do". It is: how many systems will need to agree about a unit of stock, and who wins when they disagree? Answer that and the hours follow. Skip it and you will buy tier one, discover you needed tier two in month four, and pay for both.
Here is the failure that explains the difference. A customer buys the last dress online at 14:02. A walk-in buys the same dress in your store at 14:03, because the POS has not heard about the online order and will not until the nightly sync. You now have one garment and two customers, and whichever one you disappoint is the one who writes the review.
A generic variant model does not fit garments, and apparel is where most Indian D2C brands start. That was the first thing we had to rebuild on the G4Girl fashion commerce platform.
The textbook model is product, then variant, then SKU — a dress in red at size M. Real apparel has a style, a colourway and a size curve, and the size curve is not a list of options. It is a distribution. Ordering a style means ordering a ratio of sizes, and holding "ten units" of a style that are all size XS means you hold nothing sellable.
That shape reaches everything downstream. Search has to facet on size availability rather than size existence, or you show a customer a dress that is out of stock in every size they wear. Merchandising has to rank on sellable depth. Returns have to know which size came back.
Catalogue, PIM, search and merchandising is 220 to 520 hours, the widest range in the build, and that range is almost entirely about how complex your variant model is. A single-size product is at the bottom. Apparel with size curves, and a catalogue that has to serve both retail and wholesale buyers from one record, is at the top.
That last part deserves its own sentence, because it is where a lot of Indian brands land without planning to. A wholesale buyer and a retail customer want different things from the same garment record: one needs a price list, a minimum order quantity by size ratio, credit terms and a GST treatment that differs from a consumer sale; the other needs a photograph and a size guide. Model them as two catalogues and they drift within a season. Model them as one catalogue with two presentation layers and the complexity moves into pricing, which is where it belongs and where it costs less to maintain.
This was the sentence that reframed the G4Girl project, and it generalises to every apparel brand.
Most returns in fashion are size problems, not product problems. The customer wants the same dress in a different size. If your returns flow has one path — receive goods, refund money — you convert an exchange into a refund, lose the sale, and then pay to acquire the customer again.
An exchange is a different transaction. It holds the replacement size at the moment the return is raised, rather than when the parcel arrives a week later. It nets the payment rather than refunding and recharging. It survives the replacement being out of stock by the time the goods land.
Building returns as refunds is cheap. Building exchanges properly sits inside the picking, returns and fulfilment module at 290 to 680 hours, and it is the line most often cut from a first quote and most often added back inside a year.
There is a second-order effect worth planning for. An exchange that holds stock the moment it is raised will sometimes hold stock for a customer who never posts the parcel, so the hold needs an expiry and the expiry needs to be visible to merchandising. Brands that skip this discover it as phantom stock: units the system thinks are committed, sitting against returns that never arrived, quietly suppressing sales of the size everyone wants.
If you sell in India, Gulf markets or much of Southeast Asia, a large share of orders will be cash on delivery, and COD breaks assumptions a card-first build never tests.
The order is confirmed before any money exists. So fraud and address validation have to happen at placement rather than at payment, because the cost of a bad COD order is a round trip of shipping and a garment that comes back unsellable. Refusal rates at the door are a real number that has to flow back into the customer record, because the second-time refuser should not get a third attempt.
Reconciliation is the other half. The courier collects cash, remits it on their schedule, and your ledger has to match remittances to orders that shipped weeks earlier. That is finance work the storefront never shows you.
Partial remittance is the case that breaks naive matching. A courier remits a lump sum against a batch, the batch contains a refused delivery and a short payment, and the difference has to be allocated to specific orders rather than written off to a suspense account nobody reconciles. Teams that build this properly treat the courier as a payment provider with its own settlement file, which is exactly what it is.
Storefront, checkout, payments and tax is 160 to 360 hours, and COD is one of the three things that pushes it toward the top. The other two are multi-currency and a tax regime that clears invoices before issue.
On mobile-first traffic, performance is not a polish item. It is conversion, and it is cheaper to design for than to retrofit.
The pattern we see is a catalogue that renders fast on a developer's laptop and badly on a three-year-old Android phone over a patchy connection, because the product grid ships every variant image and the filter runs client-side over the full catalogue. By the time that is visible in analytics, the architecture is set.
Peak load hardening is a stated line at 60 to 160 hours, and it is separate from the build for a reason. A storefront that holds up on an ordinary Tuesday and collapses on a sale day has not been tested; it has been used.
The specific thing to test is not page load. It is the checkout under contention: a thousand people trying to buy the last forty units of one style in the same ninety seconds. That path touches stock reservation, payment and order creation together, and it is the only part of the system where being slightly wrong produces oversells rather than a slow page.
Everything above exists in both tiers.
Order management — availability to promise, routing and allocation — at 250 to 600 hours is where the second tier starts.
The question it answers is the one from the opening: given an order, which stock location fulfils it, and what was promised to the customer at the moment they clicked. Once you have more than one source of truth — a warehouse, two stores, a marketplace — the answer stops being obvious and starts being a policy.
ERP, POS and inventory integration at 330 to 870 hours is the widest line in the whole build. The range is set almost entirely by what your ERP exposes. A modern API is at the bottom. A nightly CSV from a system whose vendor has no integration roadmap is at the top, because now you are building reconciliation rather than reading state.
Click and collect is the feature that proves whether you bought tier two properly. It needs store-level stock that a customer can trust, a reservation that survives the customer arriving four hours later, and a store colleague with a screen that tells them which units to pull and what to do when one is missing from the shelf. Every one of those reads the same availability policy, which is why it cannot be added cheaply to a build that never had one.
Subscriptions sit in their own module at 120 to 300 hours and are easy to underestimate for the same reason they were underestimated in every other vertical we price: the dunning ladder. A failed renewal is a process that runs for weeks, not an error state, and it has to agree with whatever your storefront shows the customer about their account.
Allocation policy is where the money sits, and it is a commercial decision wearing an engineering costume. Ship the last unit from the store nearest the customer and you win a delivery date; ship it from the warehouse and you keep the store's shelf full for walk-in trade that converts at a higher margin. Most brands want the second until a peak week, when they want the first. That switch has to be a setting rather than a release.
Returns routing is the mirror image and gets forgotten. A parcel sent back from a customer can go to the warehouse, to the nearest store, or to a third-party processor, and each choice changes how quickly the unit is sellable again. In fashion, where a style has a season rather than a shelf life, the difference between a unit resellable in three days and one resellable in three weeks is most of its remaining margin.
If you want the availability problem in depth rather than priced, we wrote it up separately in omnichannel inventory sync.
An ecommerce build has two prices. A D2C launch or single-channel B2B portal is 700 to 1,400 hours, roughly $42,000 to $98,000 at a $60 to $70 blend. Mid-market omnichannel, adding order management, ERP and POS integration and fulfilment, is 1,800 to 3,500 hours, roughly $108,000 to $245,000.
Every competitor publishes a total with no hours behind it. Here are the hours.
Module | Hours |
|---|---|
Discovery and integration contracts | 80 to 180 |
Catalogue, PIM, search and merchandising | 220 to 520 |
Storefront, checkout, payments and tax | 160 to 360 |
Subscriptions and dunning | 120 to 300 |
Order management: ATP, routing and allocation | 250 to 600 |
ERP, POS and inventory integration | 330 to 870 |
Picking, returns and fulfilment | 290 to 680 |
B2B, marketplace and the customer mobile app | 800 to 1,880 |
Which rows apply is the whole decision. A D2C launch or single-channel B2B portal takes the first four and lands at 700 to 1,400 hours, roughly $42,000 to $98,000 at a $60 to $70 blend. Mid-market omnichannel adds order management, ERP and POS integration, and fulfilment, and lands at 1,800 to 3,500 hours, roughly $108,000 to $245,000.
On top of whichever rows apply, every build carries the same cross-cutting lines: admin, CMS, reporting, consent and analytics at 90 to 200 hours, accounts, loyalty and wallet at 80 to 200, data migration at 60 to 260, peak load hardening at 60 to 160, DevOps and CI/CD at 60 to 160, and QA, UAT and hypercare at 20 to 25 percent of build.
These are ranges derived from module hours, not a quote. Discovery converts one of them into a fixed price.
Your ERP moves it more than your catalogue does. The integration row spans 330 to 870 hours, a swing of 540, and nothing you decide about the storefront comes close to that. Find out what your ERP actually exposes before you brief anyone, because the answer changes the architecture rather than the estimate.
Second is whether you sell to businesses and consumers from one catalogue. Wholesale buyers need price lists, credit terms, minimum order quantities and a different tax treatment, and serving both from one record is the thing that pushed the G4Girl catalogue work to the top of its range.
Third is migration. Bringing across orders, customers and a product catalogue with its images and its history is 60 to 260 hours and it is quoted at the bottom of that range roughly always.
The reason it is underquoted is that everyone estimates the export and nobody estimates the reconciliation. Historical orders reference products that have since been renamed, variants that no longer exist and tax rates that have since changed, and a migrated order that cannot be re-rendered is a customer service problem the day someone asks for an invoice copy. Decide early how much history has to be queryable rather than merely stored, because those are different jobs at different prices.
What barely moves it: the design, the number of templates, and whether the customer app is native or cross-platform.
Shopify, WooCommerce and their competitors are cheaper than any build and they work for most brands. The G4Girl platform itself runs on WordPress and PHP, because the constraint was never the storefront engine.
Buy, if your catalogue fits the platform's variant model and you sell through one channel. Most D2C brands are here and should stay here.
Build around what you own, which is where most of this work actually sits. Keep the storefront. Build the layer the platform cannot express: the variant model, the exchange flow, the availability policy across locations, the COD reconciliation. That is cheaper than replatforming and it does not put your revenue through a cutover.
Replatform only when the storefront itself is the constraint. That is a different decision with a different cost shape, and we priced it separately in ecommerce replatforming.
The cheapest useful project in this sector is also the one most often skipped: adding picking and dark-store fulfilment to a storefront you already own, at 200 to 460 hours. If quick commerce is what you are actually asking about, that build is costed here.
The pattern behind all three options is the same. Retail software is rarely one system replacing another; it is a layer added where two systems disagree. Price the disagreement, not the feature list.
Three failures, none of them technical.
The first is buying tier one while describing tier two. A brief that mentions stores, a warehouse and a marketplace is an omnichannel build whatever the budget says, and the gap shows up as an integration nobody scoped.
The second is treating returns as a refund path. In apparel it is the single most expensive simplification available, because it converts exchanges into lost sales at the exact moment the customer still wanted the product.
The third is discovering the ERP's integration surface late. It is the widest line in the build and the easiest to establish early, and the teams that ask in week one are the ones whose estimates survive.
The cost question has a short answer and it is the two tiers above. The longer answer is that an ecommerce build is priced by how many systems have to agree, and every brand that was surprised by its invoice was surprised by that number rather than by the rate.
There are two tiers. A D2C launch or a single-channel B2B portal runs 700 to 1,400 hours, which is roughly $42,000 to $98,000 at a $60 to $70 blended rate. A mid-market omnichannel build covering web, POS, one ERP, click and collect and returns runs 1,800 to 3,500 hours, roughly $108,000 to $245,000. The difference is not features. It is how many systems have to agree about a unit of stock.
One question: how many systems will need to agree about stock, and which one wins when they disagree. One sales channel and one stock location is tier one. A warehouse plus stores plus a marketplace is tier two, because order management, ERP and POS integration and fulfilment all become real modules rather than configuration. A brief that mentions stores or a warehouse is a tier two build whatever the budget says.
Because its range is set by what your ERP exposes rather than by what you want. It spans 330 to 870 hours — a swing of 540, wider than any other line. A modern documented API sits at the bottom. A system whose only supported integration is a nightly file export sits at the top, because your platform then has to reconcile state instead of reading it, and reconciliation is a permanent feature rather than a one-off connection.
Exchanges sit inside the picking, returns and fulfilment module at 290 to 680 hours. The distinction matters most in apparel, where the majority of returns are size problems rather than product problems. A refund-only flow converts an exchange into a lost sale. A proper exchange holds the replacement size when the return is raised rather than when the parcel arrives, nets the payment instead of refunding and recharging, and handles the replacement selling out in the meantime.
It moves every check earlier, because the order is confirmed before any money exists. Fraud and address validation have to run at placement rather than at payment. Door refusal rates have to flow back into the customer record so repeat refusers can be handled. And courier cash remittances have to be reconciled against orders that shipped weeks earlier, which is finance work the storefront never shows. COD is one of three things that push the checkout module toward the top of its 160 to 360 hour range.
Buy if your catalogue fits the platform's variant model and you sell through one channel — most D2C brands are there and should stay. Build around what you own when the platform cannot express something specific: an apparel variant model with size curves, an exchange flow, an availability policy across locations, COD reconciliation. Replatform only when the storefront engine itself is the constraint, which is a separate decision with a different cost shape.
Six cross-cutting lines that apply regardless of tier: admin, CMS, reporting, consent and analytics at 90 to 200 hours; accounts, loyalty and wallet at 80 to 200; data migration at 60 to 260; peak load hardening at 60 to 160; DevOps and CI/CD at 60 to 160; and QA, UAT and hypercare at 20 to 25 percent of build. Platform licence fees, payment gateway charges and courier costs are operating costs rather than build costs.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
