Rollout Context
Custom web development for two food brands on one platform
La Delizia handcrafts fresh artisan pasta daily in East Victoria Park, supplying restaurants, hotels, cafes and caterers across Perth. It also handcrafts fresh Italian cheese, under a different name, from the same premises.
That second sentence is the whole technical problem.
Two brands, one business, and a decision worth getting right
La Delizia Lab (pasta) and La Delizia Latticini (cheese) share ownership, a location and a lot of customers. But they have different products, different buying patterns and — importantly — different brand identities. Lab is warm, gold and wheat. Latticini is cool, navy and dairy. They are not interchangeable, and merging them into one undifferentiated food site would have weakened both.
The obvious approach is two separate websites. It is also the expensive one, and it carries a cost most businesses don’t see coming.
You pay for everything twice. Two builds, two hosting setups, two sets of updates. Every improvement has to be made in two places, which in practice means it gets made in one and the other slowly falls behind.
You split your search authority. This is the part that quietly costs the most. Search engines build trust in a domain over time. Two domains means two separate reputations, each starting from zero and each growing at half the rate. One domain means every page on either brand contributes to the same pool of authority.
So we built one platform serving both brands, and made the split a design decision rather than an infrastructure one.
How the shared platform actually works
The root of the domain is a brand selector: a single page that presents Latticini and Lab side by side and sends the visitor into the right world. Beneath it, /lab/ and /latticini/ behave like two entirely separate websites.
Each brand has its own header, footer, colour palette, typography and catalogue data. Put the two homepages next to each other and there is no visual clue they share a line of code.
Underneath, they share almost everything: the page templates, the product card components, the category and product routing, the image pipeline, the build process. When we improve how a product page works, both brands get it. When we fix an accessibility issue in the navigation, it is fixed twice by being fixed once.
The separation lives in data and theming rather than in duplicated code. Each brand has its own catalogue file and its own “chrome” configuration defining the identity, and the shared templates read from whichever brand’s data the current route belongs to. Adding a product to Lab does not touch anything Latticini owns.
A catalogue built for wholesale buyers
Lab is 47 pages, and 39 of them are individual product pages across five categories: long shapes, short shapes, specialty, filled and gnocchi.
Giving each pasta shape its own page rather than a row in a long list matters for two reasons.
The first is search. Someone looking for a specific product searches for that product. A single page listing forty shapes is not really about any of them, and ranks accordingly. Thirty-nine dedicated pages each get to be genuinely about one thing.
The second is that wholesale buyers need details that don’t fit in a list. Each product page carries its format, its filling or options, and its order quantity — a 4 kg box, for instance — because a chef deciding whether to put something on next week’s menu needs to know how it ships. Every product page ends with a direct order-enquiry action rather than routing people to a generic contact form and hoping they mention what they wanted.
All of it is generated from a structured catalogue file. Adding a product means adding an entry: the product page, its place in the category listing, the navigation and the sitemap all follow automatically. That is why the catalogue can grow without a developer.
Zero JavaScript, 85 pages
Across the entire platform — both brands, all 85 pages — the production build contains no JavaScript files at all.
Not “a small amount”. None. The navigation, the category filtering, the product layouts and the enquiry paths are all built from HTML and CSS.
This is unusual enough to be worth explaining. A conventional food business website on a page-builder platform typically ships several hundred kilobytes of JavaScript to every visitor, on every page, to power features most sites barely use. That cost is paid by the customer, on their connection, every time.
Here, pages arrive finished. There is nothing to execute before the content is usable, nothing to block rendering, and nothing to go wrong on an older phone in a restaurant kitchen with bad reception. Images run through Astro’s build pipeline and are served in modern formats at appropriate sizes.
The site is fast because of what it doesn’t do, which is the cheapest kind of fast to maintain.
What this pattern is good for
The two-brand platform is not specific to food. It applies to any business running multiple brands, divisions or product lines that need to look separate but shouldn’t be separate underneath: a group with several trading names, a manufacturer with distinct product families, a hospitality operator with multiple venues.
The question worth asking is whether the brands need to look different or be different. Usually it is only the first, and that is a design problem with a much cheaper solution than running parallel websites forever.
The result: a wholesale pasta website with 39 dedicated product pages, its own distinct identity, and a shared technical foundation with its sister cheese brand — one domain building authority for both, one codebase to improve, and zero JavaScript shipped to the customer.
See the live site at La Delizia Lab, or read more about our Web Design & Development service. The fresh pasta photography used throughout the site is covered in our La Delizia Lab product photography case study.
