--- title: Retail and E-commerce Platform Development description: url: https://miracuves.com/industries/retail-ecommerce date_modified: 2026-08-17 author: miracuves language: en_US --- # Commerce platforms, built for the order that comes back. Catalogue, inventory and checkout engineered alongside returns and settlement, because the reverse path is where retail margin is actually decided and it is the half most platforms treat as an afterthought. Ten commerce platforms already in production, and a custom engineering team for everything beyond them. [Talk to an engineer](https://miracuves.com/schedule-consultation/) [See what we've shipped](#shipped) Where this starts from **10**Platforms in production **8**Operator types served **2-8*wks***Custom build, scoped **6*days***Ready-made launch Returns designed inWeek one, not year two Source codeYours, in full DeploymentYour infrastructure Support, fixes, updates60 days, 6 and 12 months *Catalogue, inventory and returns* · modelled together, not bolted together Custom build Starting from a shipped platform Custom build - 2 to 8 weeks, scoped Catalogue Inventory and orders Checkout and fulfilment Returns loop Peak Launch Ready-made platform - 6 working days Rebrand, deploy, live Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our [facts page](https://miracuves.com/facts/). ## What a commerce build actually contains The sequence below is where commerce platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it. Retail has a structural asymmetry that shapes every build. The forward path - browse, add to basket, pay - is well understood and every platform does it adequately. The reverse path is where the money goes: a returned item has to be received, inspected, restocked or written off, and refunded against a payment that may have been split across a card, a voucher and a loyalty balance. Apparel operators routinely see a quarter or more of units come back, and a platform that treats returns as an exception flow will bleed margin quietly for years. Three of the seven phases have no shortcut. What a shipped platform removes is the middle: inventory and order management, checkout, and fulfilment integration. At a glance Phases7 With no shortcut3 Removed by a shipped platform3 Fixed regardless of trackCatalogue, returns, launch **01**Weeks 1-2 ### Catalogue, taxonomy and search A product is not a row. It is a family of variants across size, colour and configuration, each with its own stock, price and sometimes its own regulatory status. Fashion needs size grids that differ by brand and region. Electronics need compatibility relationships. Grocery needs weight-based units. A schema that models one of these well and the others badly limits which categories you can add later. Search is the other half and it is a conversion problem, not a technical nicety. Most commerce revenue moves through search and filters rather than browsing, which makes attribute quality the constraint. If your data does not carry the attributes people filter on, no amount of search engineering recovers it. The output is a catalogue model and an attribute standard your merchandising team can extend without a release. Variant modelAttribute standardFacetsCategory rules No shortcut here. Catalogue and attribute quality are the same problem on both tracks, and they set the ceiling on search and merchandising forever. **02**Weeks 2-3 ### Inventory, orders and the oversell problem Stock is a shared resource under contention, and every commerce platform eventually oversells something. The question is whether it happens because you chose to accept the risk or because nobody modelled it. Reserving stock at basket, at checkout or only at payment are three different trade-offs between conversion and disappointment, and the right answer differs by category and margin. The problem multiplies when stock sits in more than one place. A retailer selling from a warehouse, three stores and a marketplace listing has four systems with an opinion about availability, and reconciliation lag is measured in minutes that matter. Orders need the same discipline as any state machine: partial shipments, backorders, cancellations before dispatch, and every transition idempotent because carriers and payment providers both retry. Reservation pointMulti-location stockPartial shipmentBackorder policy **Already built**Order management with reservation policy, multi-location stock and partial shipment handling.[Amazon Clone](https://miracuves.com/amazon-clone/) · [Flipkart Clone](https://miracuves.com/flipkart-clone/) · [Walmart Clone](https://miracuves.com/walmart-clone/) **03**Weeks 3-5 ### Checkout, payments and fraud Checkout is the highest-value surface in the business and the one most damaged by well-intentioned additions. Every field, every redirect and every unexpected cost added late reduces completion. The engineering job is to make the necessary steps fast and the optional ones invisible. Payment mix is regional and non-negotiable: cards dominate some markets, wallets and bank transfer others, cash on delivery remains significant in several, and buy-now-pay-later has its own settlement and refund behaviour. Each adds a reconciliation path. Fraud controls sit here as a tuning problem rather than a switch. Too loose and you carry chargebacks; too tight and you decline good customers silently, which is the more expensive failure because nobody complains about an order they were never allowed to place. Payment mixTokenizationFraud tuningCash on delivery **Already built**Checkout with regional payment mix, tokenized cards and tunable fraud rules.[Noon Clone](https://miracuves.com/noon-clone/) · [Myntra Clone](https://miracuves.com/myntra-clone/) **04**Weeks 4-6 ### Fulfilment and the returns loop Fulfilment is an integration problem: warehouse systems, carriers, tracking updates that arrive late or not at all, and a customer expectation set by the largest retailer they have ever used. Delivery promises should be computed from real capability rather than declared, because a missed promise costs more than a slower one honestly stated. Returns are the phase teams under-build and the one that decides margin. A return has to be authorized, transported, received, inspected, and then either restocked, refurbished or written off, with the refund computed against a payment that may have been split across instruments. Each of those steps is a state, and the money is not final until inspection completes. Build this properly and returns become a measurable cost you can manage. Build it as an exception and it becomes an unmeasured one. Carrier integrationPromise computationInspection statesSplit refunds **Already built**Fulfilment integrations with a full returns loop including inspection and disposition.[Etsy Clone](https://miracuves.com/etsy-clone/) · [Aliexpress Clone](https://miracuves.com/aliexpress-clone/) **05**Weeks 5-7 ### Seller onboarding and marketplace operations If you run a marketplace, sellers are your supply and their quality is your reputation. Onboarding needs identity and bank verification, catalogue ingestion in whatever shape sellers can produce, and a review queue for the listings that need a human look. Seller payouts carry the same obligations as any split-money model: statements that reconcile, commissions computed from records, and reserves held against returns that have not happened yet. A marketplace that pays out before its return window closes has lent money without deciding to. Counterfeit and prohibited-item handling belongs here, because it is a legal exposure rather than a policy preference. Seller verificationCatalogue ingestionPayout reservesListing review **Already built**Seller onboarding with verification, ingestion and reserve-aware payouts.[Alibaba Clone](https://miracuves.com/alibaba-clone/) · [Etsy Clone](https://miracuves.com/etsy-clone/) **06**Weeks 7-8 ### Sale events and peak performance Retail traffic is not smooth. A sale event, a campaign or a seasonal peak concentrates a month of demand into hours, and it concentrates it on a small number of products, which is worse: the load lands on the same catalogue pages, the same stock records and the same checkout path. Sizing for this means caching aggressively where correctness allows and being explicit where it does not, because stock is exactly the number you cannot serve stale. Defined degradation matters: which features shed first, and whether a customer sees a queue or an error. Hot product loadCache boundariesQueueingDegradation modes **Already built**Sale-event load handling with defined cache boundaries and degradation behaviour.[Amazon Clone](https://miracuves.com/amazon-clone/) · [Fancy Clone](https://miracuves.com/fancy-clone/) **07**Weeks 7-8 ### Launch and day two A soft launch against a real catalogue, with real fulfilment, before demand spend begins. The first hundred orders teach you more about your operation than any amount of testing, particularly about the parts that involve physical goods and other companies. Day two here is the first full returns cycle, which lags the first orders by weeks and is the moment the reverse path is genuinely tested. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. Soft launchFirst returns cycleOps toolingDay two support No shortcut. Same on both tracks. A shorter build does not shorten the first returns cycle, which is the only honest test of the reverse path. Want any of these phases costed against your catalogue and return rate? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Where an order actually goes, and comes back Every commerce platform is this loop with different names on the boxes. The forward path is well understood. What separates a platform with defensible margin from one without is whether the return path was designed at the same time. At a glance Forward hops5 Return states4 Money final atInspection, not receipt Failure modes named5 **Order to cash, and the return loop**Basket to settlement, with the reverse path that decides margin BasketPayPickShipDeliver Stock reservedOr not, and you oversell Payment takenPossibly split instruments PickedShort picks happen CarrierTracking arrives late DeliveredPromise judged here The return path AuthorizedReason captured ReceivedNot yet refundable InspectedMoney becomes final Restock, refurbish or write offThree different costs Failure modes OversellSplit refund mismatchRefund before inspectionStock never restocked Forward pathThe reverse path, where margin goes Refunding on receipt rather than on inspection is the most common expensive shortcut in this sector. It feels generous and it means you refund items that arrive damaged, incomplete or not the item you sent, with no record to dispute against. ### Why a refund is not the reverse of a payment The intuitive model is symmetry: money came in, money goes back. It breaks immediately in practice. The original payment may have been split across a card, a stored balance, a voucher and a loyalty deduction, and each of those has different rules about what can be returned to it. A voucher that has expired cannot be reinstated. Loyalty points spent on a returned item may or may not come back depending on your own terms. Then there is timing. Card refunds settle on the processor's schedule, not yours, so the customer's experience of "refunded" and your ledger's view of it differ by days. A platform that models the refund as a first-class object with its own states can answer where the money is. One that treats it as a negative order cannot, and the support burden lands on people who have to guess. At a glance Instruments in one paymentOften 3 or more Refundable to originNot always Customer view and ledger viewDiffer by days Refund isAn object, not a negative Want your returns and refund model reviewed against your actual return rate? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Eight operators, eight different builds "E-commerce" is not one buyer. The catalogue shape, the return rate and the settlement model change completely between them. At a glance Operator types8 Can start from a shipped platform6 Need a custom build2 ### Multi-seller marketplaces Supply is other people's businesses. Seller onboarding, payout reserves and listing quality are the product, and counterfeit exposure is a legal matter rather than a policy one. 4 shipped platforms ### Direct-to-consumer brands One catalogue, full control, and margin that depends on repeat purchase. Simpler operationally, but the platform has to carry brand experience rather than just transact. 3 shipped platforms ### Fashion and apparel The highest return rates in retail, size grids that differ per brand, and a reverse path that dominates the operating model. Returns tooling is not optional here. 2 shipped platforms ### B2B and wholesale Account pricing, credit terms, purchase orders and approval chains. The checkout most consumer platforms optimize barely exists; the quotation flow they lack is central. 2 shipped platforms ### Cross-border commerce Duties, customs documentation, restricted goods per destination and currency exposure between order and settlement. Landed cost shown honestly at checkout is the differentiator. 2 shipped platforms ### Social and live commerce Discovery happens outside your platform and demand arrives in bursts tied to a moment. Inventory accuracy under sudden concentrated load is the whole engineering problem. 1 shipped platform ### Omnichannel retail Stores and online sharing one stock pool, with collection, in-store returns of online orders and staff-assisted selling. Stock accuracy across locations is the hard part. Custom build ### Subscription and replenishment Recurring boxes or auto-replenishment, where the product is the schedule. Skip, swap and pause logic drive retention more than catalogue depth. Custom build Six of the eight can start from something already running. Two are custom builds because nothing off the shelf carries the domain properly, and we would rather say that than sell you an adaptation that fights you for two years. Not sure which of these you are, or you sit across two of them? [Book a scoping call](https://miracuves.com/schedule-consultation/) ## How the work actually runs Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen. At a glance Stages6 Identical on both tracks5 Varies by trackStage 3 only 01Stage ### Scoping against your catalogue and return rate We start from what you sell, how much of it comes back, and where stock physically sits, because those three decide the architecture before any preference does. An apparel operator with a thirty percent return rate and an electronics seller with three percent need different platforms, and building the wrong one is expensive to correct. **Ends with**Written scope: catalogue model, expected return rate, stock locations, and the fulfilment partners to integrate first. 02Stage ### Architecture and the money model Stock reservation policy, payment instrument handling and refund states are designed before features are built, because all three are cross-cutting. Refunds become first-class objects with their own lifecycle rather than negative orders, which is the difference between being able to answer where a customer's money is and guessing. **Ends with**A reservation policy, refunds modelled as objects, and settlement rules held as configuration. 03Stage ### Build against sale-shaped data Commerce platforms fail on concentration and on stale stock, so test environments carry the shapes that matter: a sale event landing on twenty products, split-instrument payments, short picks, carrier updates arriving days late, and returns against orders that were already partially refunded. Evenly distributed test traffic proves nothing. Length varies by track **Ends with**Test data carrying sale concentration, split payments, short picks and partially refunded returns. 04Stage ### Payments, fraud and compliance validation Card data tokenized at the boundary so PCI scope stays small, fraud rules tuned against your own decline tolerance, and consumer-protection obligations checked per market. Our platforms arrive with a VAPT and compliance document, so external review starts from a documented baseline. **Ends with**A VAPT and compliance document, tokenized card handling, and fraud thresholds tuned to your margin. 05Stage ### Fulfilment integration and pilot orders Real orders through real warehouses and real carriers before demand spend begins. This stage depends on third parties more than any other, and it is where delivery promises meet actual capability rather than a service level in a contract. **Ends with**Live warehouse and carrier integrations, and delivery promises computed from measured capability. 06Stage ### Launch and the first returns cycle Soft launch, then open, with the first complete returns cycle watched closely because it lags the first orders by weeks and is the only honest test of the reverse path. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. **Ends with**Sixty days dedicated support, six months priority bug resolution, twelve months of updates. Want this sequence mapped against your catalogue and fulfilment model? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Ten commerce platforms already in production Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build. They fall into three groups, and which group you start from matters more than which name you recognise. **Horizontal marketplaces** carry seller onboarding, payout reserves and listing review, which is most of the operational surface. **Category retail** platforms carry deep catalogue structure and, in fashion, the return path that dominates the model. **Cross-border and wholesale** platforms carry duties, landed cost and account pricing rather than consumer checkout. At a glance Platforms already shipped10 Operator types covered8 DeploymentYour infrastructure, your brand [Amazon](https://miracuves.com/amazon-clone/) [Alibaba](https://miracuves.com/alibaba-clone/) [Aliexpress](https://miracuves.com/aliexpress-clone/) [Etsy](https://miracuves.com/etsy-clone/) [Flipkart](https://miracuves.com/flipkart-clone/) [Pinduoduo](https://miracuves.com/pinduoduo-clone/) [Walmart](https://miracuves.com/walmart-clone/) [Myntra](https://miracuves.com/myntra-clone/) [Noon](https://miracuves.com/noon-clone/) [Fancy](https://miracuves.com/fancy-clone/) ## What this sector requires ### A variant-aware catalogue Products as families of variants with an attribute standard your merchandising team can extend. Attribute quality sets the ceiling on search and filtering, and no search engineering recovers data you never captured. ### A stated reservation policy Stock claimed at basket, at checkout or at payment - chosen deliberately per category. Every oversell traces back to a platform where nobody decided which of the three it was. ### Refunds as objects Split across instruments, with their own states and their own settlement timing, so the platform can always answer where a customer's money is rather than inferring it from an order. ### An inspected returns path Authorized, received, inspected, then dispositioned to restock, refurbish or write-off. Money final at inspection rather than at receipt, because those are different facts with different costs. ### Honest delivery promises Computed from measured fulfilment capability rather than declared in marketing. A slower promise honestly kept costs less than a fast one missed, in both support load and repeat purchase. ### Sale-event resilience Sized for concentrated demand on few products, with explicit cache boundaries around stock, queueing rather than errors, and degradation that is designed instead of discovered. Want to open any of these platforms and look inside before deciding? [See the live demos](https://miracuves.com/solutions/) ## Stock in more than one place is a consistency problem The moment inventory sits in a warehouse and a store and a marketplace listing, four systems hold an opinion about what is available. Only one of them can be right, and deciding which is an architectural choice rather than an operational one. At a glance Systems with an opinionOften 4 or more Safe answerOne master, buffered Buffer isA margin decision Detect, do not hopeConflicts must alert **Stock across locations and channels**Who is allowed to promise a unit, and how oversell is prevented Master stock ledger One authoritative count, with a buffer per channel WarehousePhysical truth, counted late StoresSold without a system event Your storefrontReserves at checkout Marketplace listingsSells on their clock Why a buffer exists A store sale is known minutes later, a marketplace sale seconds later, a stock count days later. The buffer is the units you decline to promise, priced against the cost of an oversell in that channel. Sources of truthThe authority The buffer is a commercial decision expressed in code. On a high-margin item with a forgiving customer, promise everything. On a marketplace where an oversell costs you seller standing, hold units back. What fails is applying one buffer everywhere and calling it a setting. Want your stock model reviewed across the channels you actually sell on? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Built custom when nothing off the shelf fits The same team, working from zero. These are the capabilities we build into commerce platforms that no shipped product carries, because they are specific to how you operate. At a glance Custom capabilities6 Operator types needing custom2 ### Omnichannel stock and fulfilment One stock pool across stores and warehouses, with collection, ship-from-store and in-store returns of online orders, which is where most retail platforms stop short. [Custom software development](https://miracuves.com/service/custom-software-development/) ### Warehouse and ERP integration Two-way connections to the systems you already run, so stock, orders and financial postings flow without a reconciliation job somebody does by hand each month. [API development](https://miracuves.com/service/api-development/) ### Subscription and replenishment Recurring orders with skip, swap and pause, plus the dunning and churn logic that makes the schedule the product rather than the catalogue. [Backend engineering](https://miracuves.com/service/backend-development/) ### Cross-border and landed cost Duties, taxes and restricted-goods rules per destination, shown honestly at checkout so the customer is not surprised by a courier invoice later. [Custom software development](https://miracuves.com/service/custom-software-development/) ### Search and merchandising Relevance tuned on your own behaviour data, with merchandising controls that let a category manager promote without engineering involvement. [Data engineering](https://miracuves.com/service/data-engineering/) ### B2B quoting and credit Account pricing, purchase orders, approval chains and credit limits, which the consumer checkout model cannot express and wholesale buyers require. [Custom software development](https://miracuves.com/service/custom-software-development/) Need something this list does not cover? [Ask about custom work](https://miracuves.com/schedule-consultation/) ## What we built, and what it delivered Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for. At a glance Builds detailed here3 Marketplace ### Multi-seller platform with payout reserves Seller verification and catalogue ingestion, commissions computed from records, and reserves held against an open return window rather than paying out early. Fashion retail ### Apparel platform with an inspected returns loop Size grids per brand, returns authorized and inspected before refund, and disposition to restock, refurbish or write-off tracked as separate costs. Cross-border ### International storefront with landed cost Duties and restricted-goods rules per destination shown at checkout, with currency exposure between order and settlement recorded rather than absorbed silently. We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's. Want to speak to a reference operating in your category? [Request a reference](https://miracuves.com/schedule-consultation/) ## Written on this sector Longer pieces on the problems above, written by the engineers who build these platforms. At a glance Articles4 [Returns ### Why you should refund on inspection, not on receipt](https://miracuves.com/blog/) [Inventory ### Choosing where to reserve stock, and what it costs](https://miracuves.com/blog/) [Payments ### Split-instrument refunds that still reconcile](https://miracuves.com/blog/) [Peak ### Surviving a sale event that lands on twenty products](https://miracuves.com/blog/) If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build. Want these as a briefing pack for your board or engineering team? [Request the pack](https://miracuves.com/schedule-consultation/) We were refunding on receipt for two years. Nobody could tell me what a return actually cost us, because the system had never been asked to know. The failure pattern this page is built around That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented. [Read all forty](https://miracuves.com/client-testimonials/) ## Questions commerce buyers actually ask The ones that come up in the first call, answered as we would answer them there. At a glance Questions answered12 Can we really launch in six working days? Yes, for a shipped platform as it comes, with one fulfilment path. Warehouse and ERP integration is custom work, and it depends on the systems you already run and on their vendors. Do we own the source code? Yes, in full, deployed on your infrastructure. No per-order licence, no per-SKU fee, no runtime dependency on us. How do you prevent overselling? By choosing a reservation point deliberately and holding a per-channel buffer against the sources of truth that report late. Overselling is a risk you price rather than a bug you eliminate, and the platform should make the choice explicit. Can we sell on marketplaces as well as our own site? Yes, with one master stock ledger and buffers per channel. We will steer you away from equal two-way synchronization with no declared authority, because it produces oversells nobody can explain afterwards - but the architecture is yours to choose and we will build to it. How are returns handled? As a first-class path: authorized, received, inspected, then dispositioned. The refund becomes final at inspection rather than receipt, which protects you against items that arrive damaged or are not what was sent. What if a customer paid with a card and a voucher? The refund is modelled as its own object across instruments, with rules for what can return to each. Expired vouchers and spent loyalty points are policy decisions we make explicit rather than discover during a dispute. Do you support cash on delivery? Yes, where your market needs it, including the reconciliation path it creates and the higher return and refusal rates that come with it. How is fraud handled? With tunable rules rather than a fixed threshold, because a silent false decline costs more than a chargeback and nobody complains about an order they were never allowed to place. Can we run stores and online from one stock pool? Yes, and it is the most common custom requirement in this sector. Collection, ship-from-store and in-store returns of online orders are all scoped explicitly rather than assumed. Will it hold up during a sale event? That is the load profile we size against: concentrated demand on few products. Stock is the number we will not serve stale, so cache boundaries are explicit and degradation is designed rather than discovered. What does support look like after launch? Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. The first full returns cycle lands weeks after launch, so that window matters here more than in most sectors. What if we are not ready to build yet? We will say so. If your fulfilment operation cannot yet meet the promise your platform would make, the platform is not the constraint, and we would rather tell you that than scope work you cannot use. Question not answered here? [Ask us directly](https://miracuves.com/schedule-consultation/) ## Tell us what you are building. Bring the catalogue and the return rate. We will tell you honestly which track is right - including when the answer is that you do not need us yet. [Book a technical call](https://miracuves.com/schedule-consultation/) [Browse all solutions](https://miracuves.com/solutions/) A first call takes about thirty minutes and covers four things **01** ### Catalogue shape Variants, attributes, and which categories you intend to add later. **02** ### Where stock sits Warehouses, stores, suppliers, and who else sells the same units. **03** ### Return rate What comes back, why, and what you currently do with it. **04** ### Existing systems The ERP, warehouse and payment stack a platform must fit into. Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and whether your reverse path is quietly consuming the margin your forward path earns. If the honest answer is that your fulfilment operation needs to come first, we will say that instead of scoping work you are not ready to use.