Live demo
A working store you can sign into
A complete eCommerce platform we built as a demonstration rather than a product, where you can sign in, put something in a cart and follow the order after checkout.
Open the live demo- Add, price and organise a full product catalogue
- A checkout that takes an actual payment
- Order status tracked after the money clears
- Architecture built to hold a growing catalogue
- Optional referral layer for network-driven sales
The point where a store platform stops fitting
Most businesses start on a hosted store platform and it works, right up to the day the business does something the platform did not anticipate. A commission on a referred sale. A price that only trade customers see. An order status your warehouse actually uses. From there it is usually plugins arguing with each other.
This is not a product you can buy or subscribe to. It is a store we built and left running so the alternative is something you can click rather than imagine — where the catalogue, the checkout and the order flow are yours to change. The useful question is what an equivalent would look like built for your business.
What you can try
What you can try in the live demo
Everything here is in the demo itself. It is a showcase, so treat it as a working shape to react to rather than a feature list you are buying into.
-
Sign in and look around
The demo link opens the real application at its sign-in screen, so what you click through is the running platform rather than a marketing screenshot.
-
Product management
Add a product, set its price and file it into the catalogue, then check the same change on the storefront a customer would see.
-
A checkout that takes payment
Run a purchase through the secure payment step, rather than a buy button that quietly opens a contact form and calls itself eCommerce.
-
Order tracking
Follow an order after checkout as its status moves, from the customer's side and from the side of whoever has to fulfil it.
-
The optional referral layer
Referral integration is optional rather than assumed, for businesses where a sale has to be credited to the person in the network who brought it.
-
Room to grow
The catalogue and order handling sit on a flexible architecture, so a heavier month is a capacity decision rather than a reason to start again.
What you get
What an equivalent build gives you
This part is about your store, not the demo. What follows is what exists at the end of a build like this one, and all of it is handed over.
- YOUR STOREFRONT
- A store that matches how you sell
- Not a theme bent around your business, but a catalogue, checkout and order flow shaped to how your products are actually priced, bundled and fulfilled. The awkward parts included.
- PAYMENTS
- A checkout wired to your own gateway
- Payment handled through a provider you hold the account with, so settlement, refunds and fees are your relationship rather than a platform's cut of every order.
- ORDER VISIBILITY
- One place an order's status lives
- Order tracking where support, the warehouse and the customer read the same record, instead of three people guessing from three exports that disagree with each other.
- THE CODEBASE
- Source, repo and deploy pipeline
- In your Git organisation, so a change to pricing rules or a new fulfilment step does not depend on us being available that week, or on a plugin author still maintaining theirs.
How we work
What building your version looks like
Timelines are typical for a store of this shape. If the honest answer is that a hosted platform still fits your business, that comes out in the first conversation rather than in month three.
-
Open the demo
20 minutesClick through the live store and note what is missing for your business. That list is more useful to a first call than a requirements document.
-
Scoping
1–2 weeksWe work out what your catalogue, pricing and fulfilment actually do, then write down what stays out of the first release. Sometimes this shrinks the project.
-
Build
8–14 weeksCatalogue, checkout, payment integration and order tracking, shipped in slices you can click through on staging. The referral layer is scoped separately if you need it.
-
Launch and run
OngoingGoing live with real payments, the agreed bug-fix window afterwards, and the changes only real orders reveal. Fulfilment is usually the part needing a second pass.
Is this the right thing to be looking at?
Worth reading before you get in touch — it saves both of us a call.
A good fit if…
- You sell goods and the catalogue changes faster than a template allows
- A hosted store platform is now blocking something the business needs
- Referral or network-driven selling is part of how you grow
- You want the store's code and payment account in your own name
Probably not, if…
- A standard hosted shop still fits you, and it will cost less
- You only need payments added to a site you already have — see Custom Payment Gateway Integration
- The compensation plan is the product, not the shop — see Blockchain MLM Software
- You want a shopping app on iOS and Android — see Mobile App Development
Frequently Asked
Questions
Common questions about cost, running a store, data and how far it can be changed.
Three things, mostly. How unusual your catalogue is — variants, bundles, trade pricing, anything a template cannot express. How many systems the store has to talk to, since accounting, shipping and stock each add integration work. And whether you need the referral layer, which is a separate piece of logic with its own edge cases. A straightforward catalogue with one payment provider is a much smaller job than a store that has to reconcile with an existing ERP. We scope before quoting rather than after.
Hosting, a payment provider account, and somebody who owns the catalogue day to day. The software side is quiet: servers, backups, certificate renewals and dependency updates, which we can run for you or hand over with the deploy pipeline. The part people underestimate is the operational side. Products need photographs and descriptions, prices go stale, and orders that go wrong need a person. A store is not a project that finishes; it is a thing your business now operates.
Card details do not sit in the store. Payment capture runs through a PCI-DSS compliant provider and the application holds a token rather than a card number, which keeps your compliance scope small. Customer records, orders and addresses live in your own database, on hosting in your account if you want it that way. That matters more than it sounds: on a hosted platform your customer list sits on someone else's terms, and exporting it is their decision rather than yours.
Payments are the part that has to fail safely, so a failed charge never leaves an order half-created, and every transaction is reconcilable against the provider's own record. Beyond that: error alerting, logs you can read after the fact, and a staging environment where a change is tried before customers see it. Every engagement includes a bug-fix window after delivery. Most teams then keep a monthly arrangement, because the failures that matter tend to appear in the first busy period, not the first week.
All of it, and that is the point of it being a showcase rather than a product. Nothing in the demo is a fixed feature list you buy into. The catalogue model, the checkout steps, the order statuses and the way products are managed are decisions we make with you, and the referral layer only exists if network-driven selling is part of your model. Some of what you see will survive into your build and some will not, which is easier to work out with something real in front of you.