Building a store starts with one question:
where does the risk sit?

Short version: for a store with non-trivial stock, customer-specific pricing or a link into manufacturing, we write a bespoke build. For a store with an ordinary order flow and a product that has to be explained, we write a custom template on a hosted platform and spend the money saved on structure and content. The long version follows.

1. 01

   The decision: platform or bespoke

   We decide on a single question: where is this 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 the order logic and a bespoke build is often cheaper than bending a platform. For a store with ordinary shipping and payment and a product that has to be explained, the risk sits in the content, and a platform covers operations for a fraction of the cost. There is a cheap test we give to anyone hesitating: write a list of every page the site must have, not just categories but signposts, guides and segment pages, and try designing them into the chosen platform on paper. If they all fit, the decision is made. If two or three do not, you know before the build starts rather than three months into it.

   risk in the order = bespoke buildrisk in the content = platform and better contenttest the page list before decidinganswer before the budget
2. 02

   A custom template on Shoptet and Upgates

   When the platform wins, we do not take a stock theme and swap the colours. We write the template inside the platform from the design up, so the store looks like yours and not like a thousand others. Meanwhile the platform covers the things that get rewritten in every bespoke store and then maintained for years: the order flow with all the states you only remember once a custom build is live, carrier and payment gateway integrations that change without you, stock and variants with an admin the client can run themselves, invoices and legal texts, and hosting with backups guaranteed by a contract. 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 Rebon store was built exactly this way.

   template written from the design, not retrofittedShoptet and Upgatesorders, shipping and payments from the platformthe savings go into structure and content
3. 03

   Where a closed platform stops

   The price of that speed is that the template has fixed limits. That is not a complaint, it is the definition, and it is better to know where the limit runs than to discover it halfway through the build. The data model is already made: a product has parameters, variants and categories in the shape the platform understands, and 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 it. Performance is not entirely yours, because part of the code belongs to the platform. Outputs such as sitemaps, feeds and structured data come out the way the platform generates them; much can be added, rewriting from the ground up usually cannot. And leaving costs work: you can export the content, but the template stays where it was made.

   the data model is fixedcontent pages sit outside product logicpart of the performance belongs to the platformleaving means a new template
4. 04

   A bespoke store when the platform does not fit

   We build bespoke stores in Next.js and Node.js the same way we build websites: pre-rendered pages, our own data model, an admin shaped around whoever will use it. It makes sense where a platform gets in the way: a configurator or quote flow instead of an ordinary basket, prices and availability per customer group, a link into manufacturing, stock or an ERP, heavy filtering on attributes that platform parameters cannot express, or a B2B interface alongside ordinary retail. Expect to maintain the basket, payments and shipping yourself from then on. That is why we only go bespoke when there is a reason stronger than aesthetics.

   Next.js, Node.js, our own data modelconfigurators, B2B pricing, ERP linksan admin shaped around its usersyour own basket means your own maintenance
5. 05

   Product data, feeds and comparison sites

   In product advertising the data in the feed decides performance more than the campaign settings, so we handle the feed during the build rather than once the ads go live. That means titles and descriptions written for someone still searching, not internal warehouse labels, correct categories and attributes, manufacturer identifiers, prices and availability that match the site, and custom labels that let the advertising be split by margin. One feed then serves Google Merchant Center, Zbozi.cz, Heureka and Glami, because they read essentially the same data with different field requirements. A mistake shows up on every channel at once, and so does the fix.

   titles and descriptions written for searchidentifiers, categories, attributescustom labels for splitting by marginone feed for Google and comparison sites
6. 06

   Tracking, launch and migration

   We hand over a store with GTM, GA4 and Consent Mode v2 configured before any tag fires, our own cookie bar with no per-domain licence, and e-commerce events under consistent names an agency can build campaigns on straight away. Then we verify the thing that matters most: that the orders in analytics match the orders in the admin. Where it is needed, we add server-side tracking. When an old store is moving, we prepare a redirect map URL by URL before the domain switches, because stores lose positions quickly and regain them slowly. We design the structure around what people search for, meaning the stage the customer is at, not the way the warehouse is organised.

   GA4, Consent Mode v2 and e-commerce eventsverified against orders in the adminredirect map before the domain switchstructure from search, not from the warehouse