Storefront system
One session, and the logic underneath it.
A storefront is judged on one short session. Follow a shopper through it and watch what the system is doing at each step — because that is the part that decides whether the session ends in an order.
Sizing, delivery and returns answered here, not after checkout.
The picture changes with the colour, because the media is attached to it.
Only what can be fulfilled is offered.
Thresholds and rates are rules you set
Which options appear is decided by rules you set, not by us.
Methods shown are illustrative — yours come from your provider.
Illustrative storefront · sample data
The customer’s side
To the customer, it should feel like nothing at all.
The same session as the hero, seen only from the outside. Five moments, no decisions about catalogues, no rules to learn — just a person finding a shirt and buying it.
A good storefront keeps the buying journey simple: a customer can find the right product, understand the options, choose a variant that can actually be delivered, and reach checkout without ever needing to know the catalogue rules underneath.
The catalogue underneath
Most storefront problems are catalogue problems.
What a customer sees is decided by how one product was described underneath. Define it once — with its sizes, its extras, its pictures and its words attached to the same record — and the store mostly takes care of itself. Get that wrong and every change afterwards is a workaround.
- Sizes & coloursVariants
Size and colour are variants, because stock can differ for each one.
Black · S M LSand · S M - ExtrasOptions
Gift wrap is an option, because it does not create another shirt.
Gift wrapEngraved labelDelivery date - PicturesMedia
Pictures attach per colour, so the photo matches what was chosen.
Main imageOne set per colourFabric detail - WordsContent
Sizing, materials, care and delivery live on the product, not in a policy page.
Sizing guideMaterialsCareDelivery & returns - GroupsCollections
Collections should be rules, not lists somebody maintains by hand.
New arrivalsShirtsSummer edit
What catalogue architecture meansCatalogue architecture is how a product is defined before anything is sold. Each product is defined once, and its variants, options, media, content and collection rules attach to that same record. That structure decides what customers can see, what can actually be bought, and how the store behaves as the catalogue grows.
When it is not modelled onceThe same shirt becomes four listings, each with its own stock, pictures and search history. The shopper picks between near-duplicates, one is out of stock and still on display, and no single page is strong enough to rank.
The rules you set
Your store, your conditions.
Every business sells on its own terms. Pick a rule and watch the same cart answer to it — because this is configuration you control, not code somebody has to change.
Stock is held when someone commits, so a cart cannot quietly sell the same pair twice.
Where you cannot ship, the storefront says so before checkout rather than after payment.
What a discount is measured against is a rule too — and it has to be one you can defend.
Where you sell to businesses as well as people, who is logged in can change the catalogue and the price.
A rule that changes a cart has to explain itself in the cart, not in a policy page.
Backorder and pre-order are business decisions. Where you allow them, the storefront is honest about what it means.
These are examples of rules a storefront can express, not a list of things every build includes. Which of them your store needs is a scoping conversation about how you actually sell.
Who runs it
The people behind the storefront.
A store is edited far more often than it is built. This is one record — the same product and the order it produced — seen by each person who touches it.
Decides what is sold, how it is grouped and what leads the collection.
Owns the words and the imagery around the catalogue.
Keeps stock true and moves orders through to delivered.
Finds a customer, their order and its history in one place.
Everything, including who else has access to what.
Roles and permissions are agreed per project. What one person can see and change is a scoping decision, not a default — this is one plausible shape, not the shape you will get.
What it is built on
Themed, extended, or built for you.
A custom storefront is not automatically the right answer. It becomes the right answer at a specific point, and it is worth being honest about where that point is.
- Brand, type, colour and imagery
- Section order and page composition
- The content in every block
- The checkout the platform provides
- How products and variants are shaped
- What the cart is able to do
When it fitsA standard catalogue sold in a standard way. Most brands, most of the time — and it launches soonest.
- Everything a theme changes
- Specific behaviour added where it is needed
- A handful of screens built properly
- The platform’s checkout, mostly
- The underlying product model
- Anything the platform reserves to itself
When it fitsA few things about how you sell do not fit, and can be added without fighting the platform the rest of the time.
- The whole shopping experience
- The product model and how it is queried
- Checkout structure, within your provider’s rules
- What your payment provider allows
- What the systems you keep can expose
- The commerce engine’s own guarantees
When it fitsPricing, configuration or the systems you are keeping genuinely do not fit a product form — per-customer price lists, made-to-order products, or a storefront sitting on an ERP you own.
We recommend the leftmost option that actually works. A theme that fits is a better outcome than a custom build that did not need to exist.
How the platform decision is madeCheckout
Five steps, and what each one must not do.
Checkout is where a session is lost. Most of the damage is done by things a checkout should never do, so those are worth naming as plainly as the steps themselves.
NeverNever hide the delivery cost until the last step.
NeverNever offer a service to an address it cannot reach.
NeverNever force an account before a first purchase.
NeverNever show a method the customer cannot actually complete.
NeverNever end with a receipt and no idea what happens next.
Which payment methods and delivery services a checkout offers comes from the providers you use in the markets you sell to. They are confirmed with you before anything is designed around them.
What search sees
Easy for a customer, legible to a crawler.
A storefront has two readers. The structure that makes a store easy to shop is mostly the same structure that makes it possible to index — where it is not, the difference is a decision somebody has to make on purpose.
/shirtsThe collection. One indexable page.Indexable/shirts/classic-shirtThe product. This is the page that ranks.Indexable?colour=sandA variant of it — same page, not a new one.Canonical to the product?size=m&sort=priceA filter. Useful to a shopper, not a page.Not indexed
Structured data describes what a page shows. We do not mark up ratings or offers a store has not got — an enhancement that is not true is a manual action waiting to happen.
How search visibility is worked onRelevant capability work
Storefronts and checkout experiences we have delivered.
These are approved commerce cases whose own records name ecommerce work. They are shown for the storefront and product-experience capability behind this page.
Questions
Asked about the storefront itself.
- What is a custom ecommerce storefront, in plain terms?
- The shopping experience a customer moves through — collections, product pages, variant and stock logic, cart, delivery rules and checkout — built for how your business actually sells rather than assembled from a template. The catalogue and order data sit behind it, and the storefront is the part a customer touches.
- Is the storefront different from the wider ecommerce build?
- Yes, and the split is worth knowing. The storefront is the customer-facing system: what a shopper sees and the logic underneath it. The wider build is the project around it — platform choice, design, migration, integrations and launch. This page describes the first; the ecommerce development page covers the second.
- How is this page different from your ecommerce service page?
- This one answers what a storefront does. The service page answers who designs and builds it, how a project runs and what decides its scope. If you are choosing a partner, start there. If you are working out what a storefront needs to do before you brief anyone, you are in the right place.
- Theme or custom storefront — which do we actually need?
- A strong theme, applied well, is enough for most brands with a standard catalogue sold in a standard way, and it launches soonest. Extending a theme fits when a few things about how you sell do not fit but can be added without fighting the platform. A custom storefront becomes right when pricing, configuration or the systems you are keeping genuinely do not fit a product form. We recommend the leftmost of those that actually works.
- Can it support variants and options?
- Yes. Sizes, colours, packs and finishes are variants, each with its own stock, media and price where it needs one, mapped to a single source of truth so only what can be fulfilled is offered. Things that are not really variants — engraving, gift wrap, a chosen delivery date — are captured as options so the catalogue does not multiply.
- How should stock and availability behave?
- From one source of truth, shown honestly. In stock, low stock and unavailable are all real states, and stock is reserved when someone commits at checkout rather than when something enters a cart. Backorder and pre-order are business decisions: where you allow them, the storefront says plainly what the customer is agreeing to. Where stock lives in another system, what it can expose is confirmed during scoping.
- Can the checkout be customised?
- Within the rules of the platform and payment provider you use, which is an important limit. On a hosted platform, parts of checkout are reserved and cannot be redesigned. On a custom storefront the structure, the fields and the flow are yours to shape, but what a payment provider allows still governs the payment step. We confirm what is genuinely changeable before designing anything around it.
- Can customers use guest checkout?
- Yes, where you want it, and usually you should. A checkout should ask for what is needed to fulfil the order and nothing more, with an account offered after the order rather than demanded before a first purchase. Account checkout sits alongside it for returning customers who want saved addresses and order history.
- How does delivery logic fit in?
- As configuration you control rather than code somebody changes. Rates by weight, value, distance or zone; free above a threshold you decide; several services a customer chooses between; and products that cannot ship to some places at all. Where an address cannot be served, the storefront says so before checkout, not after payment.
- Which payment providers and methods can it offer?
- Whatever your provider supports in the markets you sell to — in India that typically means cards, UPI, wallets, net banking and cash on delivery. We do not include a provider by default: the choice is made with you, and what it supports is confirmed before it is designed in. Any methods shown on this page are illustrative.
- Who edits products and content after launch?
- Whoever you decide. Merchandising, content, operations, support and owner-level access are agreed per project, so adding a product and changing a delivery rule do not need the same permission — or a developer. What each person can reach is a scoping decision rather than something we hand you fixed.
- Can it connect to our ERP, stock or accounts?
- Where the other system allows it. We confirm what each existing tool can genuinely expose — an API, a database, a scheduled export or a documented integration — during scoping, then define the connection around what is actually there rather than what a brochure implies. Where a system cannot expose something, we say so before it is scoped in.
- Do we own the storefront?
- Yes. The design, the code and the data are yours, handed over as agreed in scope. There is no Branditify commerce product, no seat price and no version to license — this is work we build for you, not a platform you rent from us.
- Can it be headless?
- Where there is a reason for it. Headless separates the storefront from the commerce engine so the front end can be built freely and the engine keeps doing carts, orders and payments. It genuinely helps when you are serving several channels from one catalogue or need a front end a platform cannot produce. It also adds moving parts, so we do not recommend it as a default.
- Does it work properly on a phone?
- It is designed for a phone first, because that is where most of a session happens. The storefront is responsive web, so there is no app to install and no store review to wait on. A native app stays a separate decision with its own reasons for and against.
- How does storefront SEO actually work?
- Mostly through structure. Collections and products get their own indexable addresses; a variant stays part of its product rather than becoming a fourth page; filters and sorts stay useful to shoppers without generating pages that compete with each other. Titles, descriptions and structured data are written per product and describe what the page really shows. Being found once it is live is ongoing work, and that lives on the SEO, AEO and GEO page.
- Can an existing storefront be redesigned rather than rebuilt?
- Often, yes, and it is worth checking before assuming otherwise. If the catalogue is modelled sensibly and the platform is not the constraint, a great deal can change without touching the foundations. Where the catalogue itself is the problem — the same product living as four listings, for instance — that gets fixed first, because a redesign over a broken model just makes the workarounds prettier.
- What controls the scope of a storefront project?
- Mainly the catalogue and the rules. How many products and variants there are and how much of it is genuinely different; how many pricing, delivery and availability rules have to be expressed; how much content has to move and how clean it is; how many systems have to be connected and what they can expose; and how much of the checkout has to change. We scope against those rather than against a package.
Start here
Bring us the catalogue and the awkward parts.
The products, the rules that never fit a template, and the systems you are keeping. That is what a storefront has to be shaped around.