Online shops wired into the systems you already run, not next to them.
Payment, tax and fulfilment connected to the inventory and accounting that already exist, so the shop is one system instead of a website that emails someone a spreadsheet every night.
What this is
An online shop is easy to demo and hard to finish. A catalog with a buy button is a few days of work; a shop that keeps stock counts correct, charges the right tax, and gets an order to the warehouse without a human re-typing it is a different project wearing the same homepage. Most of what makes a shop actually work is invisible to a shopper and only shows up when something goes wrong.
The part that breaks first is usually the boundary between the shop and whatever already runs the business. If the shop platform and the ERP or warehouse system both think they own the stock count, they will eventually disagree, and the disagreement surfaces as an oversold item at the worst possible time. We build so there is one source of truth for inventory and one for price, and everything else reads from it. The same discipline applies to payment: a webhook that never arrives, or arrives twice, has to leave the order in a state that is correct either way, which means idempotent order creation, not a happy-path integration that assumes the network always works.
Tax is where a plugin usually stops being enough. VAT under the EU's OSS scheme, US sales tax nexus, or simply getting currency rounding consistent across a multi-region catalog are all correctness problems, not settings fields, and getting them wrong is the kind of bug that shows up on an accountant's desk months later rather than in testing. We build the tax logic to match the jurisdictions the business actually sells into, and we say so in writing rather than leaving it as an assumption baked into a template.
Platform choice follows from the catalog, not the other way round. A straightforward catalog on Shopify or WooCommerce gets to launch faster and cheaper than anything custom; a catalog with real structure, configurable products, bundles, tiered pricing by customer, or a pricing engine that already lives in another system, is where a template starts fighting the business instead of supporting it. We build on the platform that fits what's being sold, not the one we'd rather work in.
What you get
Catalog and inventory model
Wired to whichever system is the source of truth, so stock and price agree everywhere they're shown.
Checkout and payment integration
Idempotent order creation, so a retried or duplicated payment webhook cannot create two orders.
Tax calculated correctly
For the jurisdictions the business actually sells into, VAT, OSS or sales tax, not a flat rate typed into a settings field.
Fulfilment and shipping integration
Orders reach the warehouse or 3PL as data, not as something somebody re-enters.
Order lifecycle and returns
Wired to accounting so a refund posts once, in one place.
Multi-currency and multi-region
Where the business sells across borders, with rounding that stays consistent.
Back-office access
The client's own team manages products, prices and promotions without a support ticket to us.
A parallel-run launch plan
Old system and new one running side by side until stock and order totals agree, not a cutover on a Friday.
When this fits, and when it does not
A good fit
- You already run an ERP, accounting system or warehouse process, and the shop has to write to it correctly rather than duplicate it badly.
- You sell into more than one country and tax or currency handling has gotten complicated enough that a plugin no longer covers it.
- The catalog has real structure, variants, bundles or tiered pricing, that off-the-shelf themes fight rather than support.
- An existing shop has been patched around its own limitations for years and needs rebuilding on a model that matches how the business actually operates now.
Not a good fit
- You want a five-product shop live by next week on a stock theme. Shopify or WooCommerce with a template gets there faster and cheaper, and that is the right answer.
- The shop is finished and works. It just loads slowly. That's website speed optimization, not this.
- You need the storefront redesigned but the checkout, payment and inventory logic underneath already works. Talk to us about UI/UX design instead, we can restyle what's there without touching the plumbing.
- You want to sell one thing to people arriving from a single ad campaign, not run a catalog. That's landing pages.
How it runs
- 01
Map the systems
What already holds inventory, prices, tax rules and customer data, and which one stays the source of truth once the shop exists.
- 02
Build catalog and checkout
On the platform that fits the catalog's actual complexity, custom only where a plugin would fight it.
- 03
Wire payment, tax and fulfilment
Including the error paths: a declined card, a missed webhook, a courier API that's down.
- 04
Run in parallel
Old and new side by side until orders, stock and totals agree, before the old one is switched off.
- 05
Hand over
Admin access, documentation for the client's own team, and the source.
Questions we get
Which platform do you build on?
Depends on the catalog and what it has to connect to. Shopify or WooCommerce when the catalog is straightforward and speed to launch matters most, something custom when the client's ERP or pricing rules don't fit a plugin's assumptions. We pick based on what's already running, not on which platform we'd rather build in.
Can you connect the shop to our existing ERP or accounting system?
That's usually the actual project. In-house software work, including ERP-adjacent integration, is what we do day to day, so we design around the systems already there rather than asking the business to change how it operates to fit the shop.
What happens to the old shop while the new one goes live?
It keeps running in parallel until stock counts and order totals agree with the new one, days or weeks depending on order volume. A hard cutover on launch day is how a business finds its integration bugs the hard way, in front of customers.
Do you handle tax registration too?
No, that's a decision for the client's accountant. We build the shop to charge and report the rates you tell us apply, correctly and consistently. We don't advise on where a business needs to be registered.
Have a shop that needs to talk to the rest of the business?
Tell us what it already has to connect to, the ERP, the warehouse, the accounting system, and we'll tell you straight whether that's a plugin or a build.