The default answer to "we need to sell things online" is a hosted store platform, and it is the default for good reasons. It handles inventory, variants, discounts, tax, abandoned carts, and a hundred other things you have not thought of yet. It is cheaper than building. It is faster than building. It is more reliable than what you would write.
We recommend it regularly. We would rather lose the work than take on a build a platform would have handled better.
We did not use one for ICON., a streetwear label in Lebanon selling athlete graphics on tees. This is the reasoning, including the parts that argue against us.
The thing that did not fit
Almost the entire business fits neatly inside what a hosted platform assumes. Products, sizes, a couple of variants, sale pricing, a lookbook. None of that is interesting and none of it justified building anything.
The checkout did not fit.
A large share of orders in Lebanon are paid in cash, in US dollars, handed to the driver on delivery. This is not an edge case or a fallback for people without cards. For a lot of customers it is simply how buying works, and the alternatives available to them are worse in ways that have nothing to do with the shop.
Every hosted platform will let you offer cash on delivery. It is in the payment settings. But it is modelled as an exception — an unusual path bolted beside the real one, with the card form still occupying the visual and structural centre of the checkout. The customer choosing the normal local payment method is routed through what the software considers the unusual branch.
That sounds like an aesthetic complaint. It is not. It shows up as friction at precisely the moment a first-time customer is deciding whether a new brand is real, and the delivery terms — which governorate, how many days, what the driver expects — are the information they most want and the information the platform has nowhere to put.
The test we apply
The question we ask is not "can the platform do this." It nearly always can, with enough configuration. The question is whether the mismatch sits somewhere load-bearing.
A mismatch at the edge is fine. Your reporting is slightly awkward, an email template is not quite right, someone exports a spreadsheet once a month. Live with it.
A mismatch at the centre is different. When the thing that does not fit is the checkout, the permissions model, or the shape of your core data, you do not get one workaround. You get a workaround, then a workaround for the workaround, then a rule nobody can explain about why orders from one region are handled differently. Two years later the total cost of the rented option has quietly overtaken the built one, and the migration is now much harder than it would have been at the start.
For this brand, the mismatch was the checkout. So we built.
What that actually meant
Less than people expect. The build is not clever and the interesting decisions are all about what was left out.
Cash on delivery is the primary path. Not an option in a list — the default flow, with the delivery window and the amount the driver will collect stated before the customer commits. Delivery is priced per governorate, with nine of them covered and the price shown before checkout rather than after.
Accounts, because reviews needed them. Product reviews are only possible for people who signed in and bought. That is the whole reason accounts exist here. For a new brand where trust is the binding constraint, a review that can be traced to a real order is worth considerably more than an anonymous five stars.
A form asking what to print next. Customers type the name of an athlete they want to see on a shirt. It costs nothing to run and it tells the brand what its own audience wants before committing to a print run. This is the feature that would never have survived a platform's constraints, and it may be the most commercially useful thing on the site.
Product images served from object storage. Dull, and it means the catalogue can grow without the site getting slower.
That is close to the whole thing. There is no headless architecture, no microservices, no admin panel we built from scratch when an existing one would have done.
The honest costs
Building means owning things a platform would have owned.
Nobody else is patching this. Security updates, dependency upgrades, the slow accumulation of small breakages — that is now a standing obligation rather than a subscription. It is not large, but it is not zero, and it never goes away.
Features arrive when someone writes them. A hosted platform ships improvements you did not ask for and did not pay extra for. A custom build improves when you budget for it to improve. Over three years that gap compounds.
The long tail is genuinely long. Tax edge cases, fraud patterns, discount-code combinations, the exact behaviour of a cart when a product goes out of stock mid-session — a platform has encountered all of these across millions of stores. You will encounter them one at a time, in production, usually on a Friday.
We think the trade was correct here, because the checkout was load-bearing and the alternative was permanent friction at the highest-stakes moment of the funnel. We would not make the same call for a business whose payment flow was ordinary.
When we would tell you not to
If your payments, shipping and tax all work the way the platform assumes, use the platform. The build will cost more, take longer, and be worse.
If your differentiator is the product rather than the buying experience, use the platform. Engineering effort spent replicating a checkout is effort not spent on the thing customers actually came for.
If you cannot commit to maintaining it, use the platform. A custom storefront with no owner degrades faster than most people expect, and the failure is quiet — nothing crashes, it just gradually stops being good.
We say this on sales calls, and it costs us work. It is still the right advice, and the businesses we would rather work with are the ones that want to hear it.
What we would do differently
We would build the variant model before the product pages rather than alongside them. Doing both at once meant reworking one to fit the other — not a disaster, but a week that a slightly less parallel plan would have saved.
The point
"Custom or platform" is the wrong question, asked too early and usually answered by whoever has the strongest opinion in the room.
The better question is narrower: what specifically does not fit, and is it load-bearing? For most businesses the honest answer is "nothing much", and they should rent. For this one it was the checkout, which is about as load-bearing as it gets in retail.
One question, asked properly, does most of the work.