In this article
Most companies that ask us about custom ecommerce development do not need it. If you sell standard products from a single catalog, Shopify or WooCommerce will get you live faster and cheaper than anything we could build, and we say so in the first call.
The projects we do take on have something in common: the transaction itself is unusual. This article lists the questions we use to work out which side of that line a project sits on, so you can run the same check before you talk to anyone.
Look at the transaction, not the storefront
Storefronts are a solved problem. Product pages, carts, checkout, discount codes, shipping rates and tax are handled well by the major platforms, and they improve every year at no cost to you. If your platform discussion is about the storefront, a platform wins on cost, speed and maintenance.
Custom development makes sense when something about the transaction cannot be expressed in a platform's vocabulary. A standard checkout has three states: cart, payment, confirmation. The platforms in our case studies have six or more, and the extra states are where the business lives. So the first thing to write down is what happens between "the buyer wants it" and "the money has moved". If the answer is "they pay", use a platform. If the answer involves negotiation, approval, verification, escrow or payouts to someone other than you, keep reading.
Five questions
1. Do buyers negotiate?
Offers, counter-offers, time-limited bidding and reserve prices do not fit a cart. The automotive marketplace we built lets buyers make offers and fold a trade-in valuation into the deal. A property platform in our portfolio runs the entire sale as a structured bidding process. Both needed a state machine for the deal, with timers, notifications and a full history of who offered what. No plugin provides that in a form you would trust with real money.
2. Does anyone other than you get paid?
A single-seller store has one bank account at the end of the flow. A marketplace has many, and that one difference roughly triples the work. Sellers need onboarding and verification. Payments need to be split, with payout schedules, and refunds have to claw money back from a seller who has already been paid. Disputes and moderation need a workflow. Shopify can be bent into a multi-vendor shape with apps, and for a few trusted sellers that may be enough. Past that, the app stack becomes something you fight with every week. If you are building a two-sided business, the marketplace logic is your product, and you should own it.
3. Does the price depend on who is asking?
Consumer commerce shows one price. B2B commerce shows a price that depends on the account, the contract, the quantity, the credit terms and sometimes which person at the buyer is logged in. Add approval workflows, where a technician drafts an order and a manager releases it, and ERP integration so the order lands in the buyer's own systems, and you are outside what a storefront was designed for. The dealer network app we built for a multi-location equipment business is an example. Parts ordering and payments were one part of an app that also handled inventory, rentals and service scheduling.
4. Is commerce the product, or a feature inside a larger product?
A classifieds app with paid featured listings, a training app that sells subscriptions, a community platform with in-app credits. In each case commerce is one capability inside a product with its own rules, data model and user experience. You can bolt a hosted checkout onto a custom app, but the seams show, and as soon as you need wallet balances, promotional credits or usage-based charges you are writing custom code anyway. The hyperlocal classifieds marketplace we shipped makes money through in-app purchases and featured boosts. That is commerce, but no storefront platform would recognise it as such.
5. Will most buyers use a native app?
If most transactions will happen in a mobile app, the storefront platform becomes a backend and the app is where the work is. Native payments, push notifications, carts that survive a lost connection and app store review rules all belong to mobile engineering rather than to the ecommerce platform. At that point the question changes from "Shopify or custom" to "which backend does our app talk to". Sometimes the answer is a headless commerce API. Often it is a purpose-built one.
What custom should still not mean
Choosing custom development does not mean building everything. A few rules hold regardless of platform.
- Payments are never custom. Card data goes to a PCI-compliant gateway through its official SDK and never touches your servers. We build the experience around the gateway: saved cards, subscriptions, refunds, split payouts and reconciliation.
- Tax and shipping calculation are bought, not built. The rules change constantly, and the vendors who track them cost far less than getting a rate wrong.
- The money path gets extra care. Payment operations are idempotent so a retry never charges twice, inventory cannot go negative, and payout maths is tested against the accountant's spreadsheet before launch.
A quick way to decide
Count your yes answers. Zero means use a platform and spend the budget on marketing. One is worth a conversation, because a well-chosen app may cover it. Two or more means the transaction is the hard part of your business, and a platform will fight you on the thing that makes you different.
If you are not sure which bucket you are in, describe your transaction to us and we will tell you which route we would take. Our ecommerce development page covers the kinds of platforms we build, and scoping is free.