Published 30 October 2026 · 4 min read
A content-heavy store on a closed platform: when it is enough and where it stops
The question of platform versus bespoke is usually treated as a matter of taste. It is not a matter of taste; it is a matter of where the risk in the project sits. For the Rebon store it sat in the content, not in the basket, and everything else followed from that.
- In short
- An existing platform makes sense where the risk is in the content and the customer journey, not in order logic. Baskets, payments and stock are not where a project is won.
- A closed template has fixed limits. Anything that does not fit has to be solved another way, not worked around, and that has to be known before building starts.
- The decision can be tested up front: list the pages the site must have and try designing them into the platform before you commit to it.
Where the risk in a project sits
The choice between an existing platform and a bespoke build does not rest on what is prettier or more modern. It rests on a single question: where is this particular project most likely to go wrong.
For a store with thousands of lines, non-trivial stock, customer-specific pricing or a link into manufacturing, the risk sits in order logic. There a bespoke build is often cheaper than bending a platform. For a store with twenty lines, ordinary shipping and payment and a product that has to be explained, the risk sits somewhere else entirely: in whether the customer understands what they are buying.
That is exactly what Rebon is, a store selling domestic water filtration. Twenty-one lines, no unusual commercial logic, but a product where people do not know what is in their water, do not understand the difference between cartridges and have no idea whether they can fit it themselves. The basket was not where the project could be won or lost.
What a platform saves
As a platform, Upgates covers the things that get rewritten in every bespoke store and then maintained for years:
- The order flow from basket to shipment status, including the states you only remember once a bespoke build is live.
- Shipping and payment with carrier and gateway integrations that change without you.
- Stock, variants and availability with an admin the client can run themselves.
- Invoices, returns and legal texts in a form you do not have to look up in a regulation.
- Operations, backups and updates guaranteed by a contract rather than by your availability.
None of that is interesting work and all of it has to work. The money not spent there goes where the outcome is actually decided: the template, the structure of the pages and the content.
Where it stops
The cost is that the template is written inside the platform and its limits are fixed. That is not a complaint, it is the definition. What matters is knowing where the limit runs before building starts:
- The data model is already made. A product has parameters, variants and categories in the shape the platform understands. An entity that does not fit can be simulated, not invented.
- Content pages are not products. They fit, but they behave differently from categories, and the design has to allow for that or you end up with two templates for the same thing.
- Performance is not entirely yours. Part of the code and part of the loading belong to the platform. You can optimise what you control, which is usually plenty, but not everything.
- Outputs have their own shape. Sitemaps, feeds and structured data come out the way the platform generates them. Much can be added; rewriting from the ground up usually cannot.
- Leaving costs work. You can export the content, but the template stays where it was made.
How to decide before you start
There is a cheap test for this that we recommend to anyone hesitating. Write a list of the pages the site must have — not the categories, all of them: signposts, guides, segment pages, pages for the undecided. Then try designing them into the chosen platform on paper.
If they all fit, the decision is made and you have saved yourself a bespoke store. If two or three do not fit, you find out while something can still be done about it, rather than three months into the build. At Rebon they all fitted, including the signpost of water source → what you are solving → where to start, the segment pages for offices, hospitality and aquariums, and the content pages on choosing a filter.
What still has to be done by hand
A platform solves operations; it does not solve decisions. A category structure that follows the customer's stage, titles and descriptions for every page, structured data on frequently asked questions, one canonical domain, measurement from day one and an accessibility statement — all of that is work nobody does for you, and all of it decides whether the store gets found at all.
The reverse holds too: had we written this store from scratch, none of it would have been done for us either. We would simply have had a basket of our own to maintain for years on top.
Our sister studios look at the same project from other angles: DHMO on branding a product the customer does not understand and Independency on structuring a store around search.
Contact
Have a project? Write to us.
A few sentences about what you are dealing with is enough. We reply within one working day with questions and a proposed approach.