Stores That Take Money Reliably, on the Platform That Actually Suits You
Custom storefronts, checkout and payment integration, subscriptions, inventory and fulfilment, multi-vendor marketplaces. And a straight answer about whether you need a custom build at all — because plenty of businesses don't.
Platform Build or Custom Build
This is the choice that sets your budget, your timeline and how much of your life you spend on maintenance. It deserves ten honest minutes before anyone writes code.
Shopify or WooCommerce, built properly
The platform already solves payments, tax tables, shipping rates, fraud screening, discount codes and the admin your team will use daily. We build the design, the parts that are specific to you, and the integrations into your other systems.
- Live far sooner, with far less to go wrong
- Security patches and compliance are someone else's job
- Your staff can hire for it, because thousands of people know it
- Trade-off: you live inside the platform's rules and its fees
- Typical build time
- 4–10 wks
- Ongoing cost shape
- Monthly fee
Your own storefront and checkout
Everything is yours to define, which is the point and also the cost. You are now responsible for the things the platform used to handle, so this only pays off when the platform genuinely cannot express how you sell.
- Pricing, bundling and approval rules can be anything you need
- No per-order platform cut, and no plugin you cannot fix yourself
- Deep integration with your ERP, pricing engine or production system
- Trade-off: tax, fraud, uptime and upgrades all become yours
- Typical build time
- 12–24 wks
- Ongoing cost shape
- Hosting + team
Illustrative comparison of the two approaches in general terms — timings are indicative ranges for scoping conversations, not a quote or a record of a specific project.
When Custom Is Justified, and When It Is Vanity
Wanting your own checkout because a platform feels beneath your brand is not a business case. These are.
Your pricing isn't a price
Quantity breaks per customer, contract rates, quote-then-order, configurable products where the price depends on six choices, approval before an order is allowed to proceed. When pricing is a calculation rather than a number on a product, platforms start fighting you.
The store is a front end for another system
Stock, pricing and lead times live in an ERP or a production system, and that system is the truth. Once the store is mostly a well-designed window onto software you already run, building the window yourself is often simpler than bending a platform into shape.
You are the marketplace, not the seller
Many sellers, split payments, held funds, seller onboarding and payouts. Platform marketplace add-ons exist and some are fine, but once money is flowing to third parties on your behalf the rules get specific, and specific usually means custom.
Ten plugins would have done it
If the honest gap between what you need and what the platform does is a handful of settings and one integration, custom will cost several times as much and give you a worse admin screen. We have talked people out of this and kept them as clients.
The real problem is the design
Slow, ugly or confusing platform stores are usually badly built platform stores. A custom theme and a proper performance pass fixes that for a fraction of a rebuild. Rewriting the engine to fix the paintwork is a very expensive way to redecorate.
Nobody has bought anything yet
Pre-revenue, prove the demand on a platform first. It is faster, cheaper and completely reversible — and if the products sell, you will make far better custom decisions with a year of real order data behind you.
The Pieces of a Working Store
Every one of these has a boring version that works and an ambitious version that eats your budget. We are direct about which is which.
Storefront and Catalogue
Product pages, variants, and search and filtering that survives a catalogue of thousands rather than the twelve you launch with — the point where AI-assisted search starts earning its cost. Editors get a way to merchandise without calling a developer.
Checkout and Payments
Cards, wallets, buy-now-pay-later and saved payment methods, with tax and shipping calculated before the shopper has to guess. Fewer steps, no forced account creation, and errors that say what went wrong.
Subscriptions and Recurring Billing
Plans, trials, pauses, skips, upgrades mid-period, proration, retries on failed cards and the dunning emails that recover them. The billing is easy; the edges are the project.
Inventory and Fulfilment
Stock synced with your warehouse, ERP or 3PL, label generation, tracking numbers pushed back to the customer, and a sane answer for what happens when two people buy the last one at once. Where the warehouse still runs on a spreadsheet, that is an internal tool project first.
Multi-Vendor Marketplaces
Seller onboarding and identity checks, listings, commission, split payments, held funds and payout schedules. The storefront is the easy half — see the section below for the other one.
Performance Work
Image handling, caching, deferred scripts and a merciless look at the third-party tags slowing the page down. On a store, speed is not a technical nicety — it is revenue.
Keep Card Data Off Your Servers. All of It.
PCI DSS scope is the set of systems that touch cardholder data, and every system inside it becomes something you have to secure, document and answer for. The whole art is making that set as close to empty as possible.
We do that the standard way: the card fields belong to the payment provider, rendered in your checkout but hosted by them, so the number never passes through your code. The provider returns a token, and your system stores the token. Refunds, saved cards and repeat billing all work off that token. If your database is ever breached, there are no card numbers in it to lose, and your compliance obligation stays at the lightest self-assessment tier rather than a full audit.
- Hosted card fields, tokens stored instead of card numbers
- Strong customer authentication handled where your buyers need it
- Webhooks verified and replay-safe, so a lost message cannot lose an order
- Payment accounts in your name, with the keys in your possession
The Part of a Marketplace That Is Actually Hard
Two-sided marketplaces look like a store with more sellers. The storefront is the small half. Moving other people's money is the large one.
Payouts and split payments
- Every order can split between several sellers, your commission, shipping and tax
- Payment providers offer connected-account models built for exactly this — use them, do not reinvent it
- Sellers must be onboarded with identity and bank verification before they can be paid
- Payout schedules, minimum thresholds, failed transfers and a statement each seller can reconcile
Escrow and held funds
- Holding money until delivery protects buyers and is often the reason your marketplace is trusted
- It also means you are holding funds that are not yours, which carries real regulatory weight
- The release conditions need to be written down precisely: what triggers release, what blocks it, who can override
- We build this on a provider that supports delayed payouts rather than parking cash in your own account
Disputes, refunds and chargebacks
- A refund after payout means clawing money back from a seller who has already spent it
- Decide the policy before launch: reserves, rolling holds, or your commission absorbing the loss
- Chargebacks arrive weeks later with evidence deadlines, so the case file has to be assembled automatically
- The admin tool for handling all this is a real product in its own right, not an afterthought
Trust, quality and the cold start
- Seller verification, listing review and a way to remove a bad actor quickly and completely
- Reviews that cannot be gamed, and a dispute path that does not depend on you reading every email
- Your first problem is usually supply, not software — an empty marketplace converts nobody
- We would rather build you a smaller launch and leave budget for getting sellers on board
Performance Is a Conversion Feature
On a store, every extra second between tap and content is shoppers leaving. This is the cheapest revenue work available to most teams.
Measure real devices
Not a score from a fast laptop on office fibre. Field data from the phones and networks your customers actually use, because that is the store they see.
Fix the images first
Modern formats, correct dimensions, lazy loading below the fold and a real width and height on every image so the page stops jumping while it loads.
Audit the third-party tags
Analytics, chat widgets, review scripts, five pixels nobody remembers adding. This is where most store slowness lives, and some of it can simply go.
Shorten the checkout
Fewer fields, address autocomplete, wallets offered first, no forced account creation, and clear errors. Speed gets them there; friction is what loses them at the end.
Ecommerce Questions We Get Asked
Should we just use Shopify?
Often, yes, and we will say so. If you sell physical products through a fairly standard checkout, a platform gets you live in weeks with payments, tax, shipping rates and fraud checks already solved, and we build the design and the integrations on top of it. Custom becomes the right call when your pricing, bundling, approval steps or fulfilment rules cannot be expressed in the platform without a pile of fragile plugins holding each other up.
How much does an ecommerce build cost?
A well-built platform store with custom design and a couple of integrations usually lands in the low tens of thousands. A custom storefront with its own checkout, subscription logic or marketplace payouts starts higher, and the number scales with how many systems it has to talk to rather than how many products you sell. The cost calculator gives an indicative range, and we confirm a real figure once we have seen your catalogue and your integration list.
Do you store credit card numbers?
No, and neither should you. Card details go from the shoppers browser straight to the payment provider, which hands back a token that your system stores instead. That keeps raw card data off your servers entirely and keeps your PCI obligations at the lightest self-assessment tier. Any developer offering to store card numbers on your behalf is building you a liability, not a feature.
Can you build subscriptions and recurring billing?
Yes. Charging a card every month is the easy part. The hard parts are the edges: failed payments and retry rules, upgrades part way through a billing period, pauses and skips, proration, dunning emails, tax on recurring charges, and what a customer sees the day a card expires. We scope those explicitly at the start, because they are where subscription projects overrun.
Can you migrate our existing store?
Yes. Products, variants, customers, order history and addresses all move across. The addresses matter most: a migration that changes every product URL without redirects can cost you search traffic that took years to earn. We map old URLs to new ones, keep order history readable to your support team, and run the old and new stores side by side until the numbers agree.
Tell Us What You Sell and How
Send us your catalogue size, your pricing rules and the systems it has to talk to. We'll tell you whether a platform will do it, what custom would cost, and which we would choose in your position.