Online shops you own.

Our stores start from about ₹12L, and it is worth being precise about what moves that number, because it is rarely what people expect. Page count barely matters. The cost drivers are the structure of the catalogue (a hundred simple products is a smaller job than thirty configurable ones with specifications and variants), the pricing logic (one list price for everyone is trivial; per-account contract pricing with volume breaks is engineering), and the integrations — whether an order has to reach an ERP, stock system or accounts package rather than an inbox.

A hosted platform prices differently: a monthly subscription, apps on top, and on most plans a percentage of every transaction. At low volume that is genuinely cheaper than a build, which is why we recommend it for simple shops. The crossover comes as volume grows and the percentage compounds, or the moment your pricing model stops fitting what the platform permits — the point where you start paying developers to fight the platform instead of extend it.

Integration work is priced after technical discovery against your actual systems, never from a feature list. That discipline is the same one we apply to software generally: the surprises in commerce projects live in the pricing rules and the data quality, and the cheap place to find them is week one.

Every rented platform makes the same trade: convenience now for control later. The checkout is where that trade bites, because the checkout is where your pricing model, your payment terms and your customer relationship actually live. On a consumer platform those are configuration options, and your business model has to fit inside whichever options exist. A trade business offering credit terms, negotiated pricing and purchase-order flows is not a configuration of a consumer shop — it is a different machine.

Medusa changes the ownership, not just the bill. The commerce engine is open source, the code and data are yours, the payment account is in your name, and a pricing rule the platform never anticipated is an afternoon of engineering rather than a workaround stacked on an app on a plugin. That is also the honest reason it is not for everyone: ownership means somewhere to run it and someone accountable for it, which is what hosting and the retainer are for.

The direction of travel matters too. More B2B purchasing is moving online, buyers increasingly expect consumer-grade ordering at trade terms, and the businesses that own their commerce stack get to meet that expectation at their own pace — not at their platform's roadmap.

Most stores we build replace an existing one, and the replatform is where the commercial risk concentrates. The store that exists has rankings, customer accounts, order history and buying habits, and all four are easy to destroy with an enthusiastic migration. The discipline is unglamorous: baseline current behaviour before touching anything, map every product and category URL one-to-one for redirects, migrate accounts and order history rather than asking customers to start again, and switch over in stages where the risk is high.

The redirect map deserves particular respect in commerce, because product URLs carry rankings that took years to earn and category pages often outrank the homepage. A blanket redirect to the new homepage reads as a soft 404 to search engines, and the traffic loss lands in the same quarter you are trying to justify the build.

The measure of a good replatform is that your buyers barely notice — the store just got faster, the prices are still theirs, and reordering still works from muscle memory. The improvement shows up in the numbers, not in a retraining exercise for your existing customers.