31. 10. 2026·18 min read

Restaurant, Online Store and Delivery: One System or Three Products?

A tablet with the LavShash restaurant, market and delivery sections, linked by red lines to the three counters behind it, cover of a Peretz article on one system for a food business

A restaurant with its own market and delivery usually gets three separate proposals: a restaurant website, an online store and a delivery app. We were in that situation with LavShash and designed one system with three customer journeys instead. Here is what such a system shares, what each channel keeps for itself, where apps fit, what to build first, and when three separate products really are the better choice.

IN SHORT

One system, three journeys

If one business sells through a restaurant, a shop and delivery, it needs one system underneath and a separate journey for each channel on top. The catalog, stock, customers, orders and admin live once. The interfaces differ, because people who shop, order dinner and book a table want different things. Three separate products look cheaper at the start and cost more every month after.

We came to this with LavShash, a business with a restaurant, a gastro market of roughly 2,000 to 3,000 products and its own delivery. Most of the proposals it had received followed the same model: a restaurant website, an online store and a delivery product, each on its own. We proposed one digital ecosystem around three customer journeys, designed it, and built the site, the market and native iOS and Android delivery apps. The system is built and ready; its launch is on hold.

Here we take the decision behind the case, one system instead of three products, and turn it into questions any owner of a multichannel food or retail business can apply before signing three contracts with three vendors.

Three products under one logo are still three products for the customer.

THREE QUOTES

Why owners get three proposals

The split usually comes from the market, not from the business. A studio that makes restaurant websites quotes a restaurant website. An e-commerce team quotes a store. An app studio quotes an app. Each proposal solves the task in front of it. What none of them owns is the space between the three.

That space is where a multichannel business actually runs. A dish appears on the restaurant menu and in delivery. A jar of sauce sits on the market shelf and gets added to a delivery order. The same family visits on Saturday, orders on Wednesday and buys groceries online on Sunday. If the three products were built separately, each of these moments becomes a question of synchronization: who updates the price in three places, which system knows the customer, where the order history lives.

The owner ends up as the integrator. Staff copy data between admin panels, the accountant reconciles three sets of reports, and every new idea (a loyalty program, a gift card, a combined order) turns into a project across three codebases and three contracts. At LavShash we could see that the separate model would technically solve the immediate tasks, and that the customer would end up with several independent digital products that simply happened to belong to the same brand.

Our approach starts one step earlier. We look at the business as a whole and find where its channels are really different and where they are parts of the same system, and only then design interfaces around that logic. The same idea, applied more broadly, is in Most Companies Don't Need a New Website. They Need a New Structure.

SHARED CORE

What lives once, and what stays separate

The useful question is not "one site or three" but "which data and rules belong to the business, and which belong to a channel". The first group should exist once. The second can differ as much as each channel needs.

Layer	Lives once, for the whole business	Differs by channel
Products and dishes	One record per item: name, photos, ingredients, allergens, price rules	Where it is shown, in what order, with which description
Stock and availability	One view of what is available, per location	What each channel may sell: market stock, kitchen capacity, delivery hours
Customers	One account, one address book, one consent record	What each journey asks for and remembers
Orders and payments	One order model, one payment setup, one refund process	Order type: cart, delivery slot, table booking
Content and brand	One media library, one brand system	Tone and layout: selling, ordering, inviting
Admin and reports	One admin panel, one set of numbers	Views for each team: kitchen, market, couriers

Food adds detail that general e-commerce does not have. A dish has a kitchen behind it, with hours, capacity and a menu that can change by the day. A market item has a physical stock count, an expiry date and sometimes a price by weight. A good shared core keeps both in one catalog with different availability rules, so a manager changes an allergen note once and it is correct on the restaurant page, in the market and in the app.

We described the same principle for retail, wholesale and partner channels in When E-Commerce Becomes a Business System. That article deals with prices by account and stock allocation between trade channels. In a restaurant business the pressure points are different: kitchen time, delivery zones and a customer who switches between eating in, ordering and shopping within one week.

In LavShash, each part kept its own logic and its own journeys, and from the outside everything remained one brand on a shared architecture. The gastro market inside it was a full online store in its own right, with categories, search, filtering, product cards, a cart and checkout, the kind of store our e-commerce development work is about. The store had first been built on Magento by a previous contractor and was rebuilt on Laravel around the business rules; why, and what that changed, is in Leaving Magento in 2026.

ONE CUSTOMER

One account, one history

Picture a regular customer. On Saturday they buy cheese and wine at the market. On Wednesday they order dinner home. On Friday they come to the restaurant with friends. With three separate products, the business has met three strangers. With one system, it knows one person with one history.

That difference shows up in places owners care about:

Service. The delivery app already knows the address used for the last market order, and a complaint about a delivery can be seen next to the customer's restaurant visits.
Messages. One consent record decides who may receive news and offers, instead of three lists with three sets of unsubscribe rules.
Loyalty. Points, gift cards or a birthday offer work across channels, because there is one account to attach them to.
Numbers. The business can see how many customers use more than one channel and what they spend in total, a question three separate databases cannot answer without manual matching.

One account does not mean one interface. A customer can move from the restaurant page to the market and keep their login, cart and preferences while the screen around them changes completely. That is what we mean by one ecosystem with three journeys: the restaurant invites, the market sells, delivery makes ordering effortless, and the customer stays the same.

Data protection gets simpler as well: personal data sits in one place, with one set of access rights and one process for a deletion request, instead of three vendors and three databases to search.

DELIVERY

Delivery is a product of its own

Delivery is the channel that gets underestimated most often. On a restaurant site it tends to start as a menu page with a phone number. Once orders grow, it becomes a service with its own rules: zones, minimum orders, time slots, kitchen load, couriers, order statuses and refunds.

At LavShash we never treated delivery as a menu page. We designed it as a full service, a website plus native iOS and Android apps, where a user could choose dishes, place an order and interact with the service whether they were at the restaurant or at home.

Five questions decide the delivery logic of a multichannel food business:

Can one order mix kitchen dishes and market goods? It sounds convenient, but cooked food has a short window and a market order can be packed hours ahead. Some businesses allow it with one delivery time; others split it into two orders behind one payment.
Who decides the slot, the kitchen or the courier? If the kitchen is full at 7 pm, delivery should stop offering 7:30 instead of accepting the order and apologizing later.
Which zones, at what price? Zones and minimum orders are business rules, and they change. They belong in the admin panel, where a manager can edit them, rather than in code.
What does the customer see after paying? Accepted, cooking, on the way, delivered: each status is a message the business either sends or ends up answering by phone.
How do refunds work? A missing item in a market order and a cold dish need different handling, but both should run through the same order history.

Owners also ask whether they need their own delivery at all when aggregators exist. Aggregators bring reach, and many restaurants use both. The price is a commission on each order and the customer relationship: in the US, DoorDash's Marketplace plans charged restaurants 15%, 25% or 30% per delivery order as of October 2026, and the customer remains the platform's customer. An own delivery channel keeps the customer, the data and the rules with the business. It also has to earn its keep, which is why it should run on the same core as everything else rather than as a fourth product.

Delivery stops being a menu page the moment orders start repeating.

ENTRY POINTS

The homepage is not the front door

A system with three journeys raises a practical question: where does the customer come in? The habit is to send everyone to the homepage and let them choose. Most people arrive with a narrower intent: a specific product, a dish, delivery tonight, or the restaurant itself.

In LavShash we did not treat the homepage as the required entry point. Search traffic landed directly in the relevant part of the product: someone searching for a product came into the gastro market, someone searching for delivery came into delivery, someone searching for the restaurant came into the restaurant. From there, the user stayed inside the same ecosystem. This let us combine two things that often pull against each other, deep specialization in each section and coherence as one product.

For a business planning its own system, that turns into a few concrete decisions:

one brand domain with clear sections for the market, delivery and the restaurant, each with pages built for its own searches;
navigation that lets a person cross between journeys without losing their account or cart;
a homepage that works as a crossroads for people who come by name, not as a gate everyone must pass.

Three separate domains split the brand's presence in search and turn every cross-link into an exit to another site. One domain with three sections keeps the customer in one place and lets each section speak the language of its own visitors.

APPS OR WEB

Native apps or the mobile web?

Owners are often offered an app for every channel. In our experience one app is usually enough, and in some businesses none is needed. The test is frequency: an app earns a place on a phone when it makes a repeated action easier. Ordering dinner again to a saved address is such an action. Looking at a restaurant's interior or a market catalog once a month is not.

That is why, at LavShash, delivery got native iOS and Android apps, while the restaurant and the gastro market lived on the web. Delivery was never meant to feel like a mobile version of the restaurant's website. A customer who orders often needs speed: their address, their last order, their payment method and a status they can follow.

The mobile web has grown much stronger. Since iOS and iPadOS 16.4, a web app added to the Home Screen can ask permission to send push notifications, as Apple's WebKit team announced with that release. For a market or a restaurant, a fast mobile site that can be installed as a web app covers most needs at a fraction of the cost of a store app. Apple sets its own bar from the other side: the App Store Review Guidelines ask that an app "elevate it beyond a repackaged website", so wrapping the website in an app shell is not a plan.

How to choose in practice:

Channel	Mobile web is usually enough when	An app earns its place when
Gastro market	Customers buy occasionally and browse the catalog	Weekly baskets repeat and saved lists matter
Delivery	Orders are rare or come mostly from first-time visitors	The same customers order often from saved addresses
Restaurant	The site invites, shows the menu and takes bookings	Rarely, unless loyalty or ordering at the table is central

We build native apps in Swift and Kotlin or one React Native app, depending on what the product needs, together with the back end and the admin panel, as described on our mobile app development page; a full app usually takes 10 to 20 weeks. For a multichannel business the key point is that the app is one more interface to the same core, with no catalog of its own. The broader decision, including progressive web apps, is in When Does a Business Actually Need a Mobile App?

RUNNING COSTS

What three products cost to run

Everyone compares the build price, the least telling number. A multichannel business pays for its digital products every month, and here is how the two models compare on the work that never stops:

Ongoing work	Three separate products	One system with three journeys
Price and menu changes	Entered in up to three admin panels, or synchronized by scripts	Entered once, shown everywhere
Stock and availability	Matched between systems, with a risk of selling what is gone	One view, rules per channel
Integrations: payments, accounting, couriers	Built and maintained up to three times	Built once
Security and platform updates	Three codebases, often three vendors	One codebase, one plan
Customer data and consents	Three databases to protect and search	One database
A new feature across channels	Three projects to coordinate	One project
Responsibility when something breaks	Shared between vendors	One team

Apps add a layer of cost that never goes away. As of October 2026, Apple's Developer Program costs $99 a year and Google Play charges a one-time $25 registration fee. Both stores raise their technical requirements on a schedule: since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK, and from August 31, 2026, new apps and updates on Google Play must target Android 16 (API level 36). An app has to be updated every year even if nothing in the business changes. In a three-product setup, the delivery app is the product most likely to be left without an owner.

One system costs more to design. The shared core, the account model and the order logic have to be thought through before the first screen is drawn, and that work is visible in the first estimate. It pays back in the second year and every year after, when the business adds a channel, changes its menu or starts a loyalty program without commissioning three projects.

For orientation, our starting prices as of October 2026: an online store from $25,000, a mobile app from $30,000, business digitalization work from $15,000. A system like this combines parts of all three, so the real estimate comes after the business has been mapped. The rest of our prices are on the pricing page.

The cheapest quote at the start is rarely the cheapest system to run.

BUILD ORDER

What to build first

One system does not mean building everything at once. It means designing the whole and building in an order that brings value early. This is the sequence we recommend:

Map the business. Channels, products, stock, customers, the kitchen, couriers, and the accounting and POS systems already in place. A strategic session gives the first answer in two to three hours; a discovery phase turns it into documents, a prototype and an estimate.
Design the shared core. Catalog, availability rules, the customer account, the order model and the admin panel. This is the part that makes later channels cheap.
Launch the journey that already has demand. For one business that is the market, for another it is delivery. The first channel helps pay for the next ones.
Add the second and third journeys on the same core. Each gets its own interface; none gets its own database.
Add apps when the repeat behavior is visible. A delivery app makes sense once people come back for it, and by then the core already serves it data.

The order depends on the business. At LavShash all three journeys were designed together, from Figma to code, and built: the site, the market and the native delivery apps. The system is ready and the launch is on hold, and the idea that one ecosystem serves three journeys better than three products has not changed for us.

Who builds it matters as much as the order. A system like this needs one team that understands the business logic across all channels: front-end and back-end developers, a mobile developer, a designer and someone who owns the architecture. We assemble such teams from people we know and have vetted, either for a fixed-scope project or as a dedicated development team that stays with the product month to month. In either format the code and deployment are handed over to you under the contract, so the system belongs to the business. The engineering side of platforms like this is on our web application development page, and the wider work of moving operations into one system is on business digitalization.

WHEN SEPARATE

When separate products are right

One system is not always the answer. Separate products make sense in four situations:

The channels are separate businesses. Different brands, different audiences, at times different owners. If the market could be sold on its own next year, its system should be able to leave with it.
A channel is an experiment. If delivery is a three-month test, an aggregator or a simple ordering tool is a cheaper way to learn than building it into the core. Bring it in once it proves itself.
The restaurant only needs to invite. A site with a menu, photos and a booking widget from a reservation service may be enough, and there is little to share with a store.
The operations do not overlap. No shared products, no shared customers, no shared stock. Then integration costs more than it saves.

Even then, decide early where customer data lives and who owns it: separate customer lists are the hardest part to join later.

The question to ask any vendor is simple: if we add a fourth channel in two years, what changes in your system? If the answer is "another project of the same size", the business is buying products. If the answer is "a new interface on the existing core", it is buying a system.

FAQ

Frequently asked questions

Can one platform run a restaurant website, an online store and delivery?

Yes, if it is designed as one system with separate journeys: one catalog, one view of stock, one customer account and one order model, with different interfaces for shopping, ordering and visiting. We designed LavShash this way, with the gastro market, delivery with native apps and the restaurant in one ecosystem.

Do we need a separate app for each channel?

Usually not. An app earns its place where customers repeat an action often, which in food businesses is most often delivery. A market and a restaurant usually work well on a fast mobile site, which since iOS 16.4 can also send push notifications as a Home Screen web app.

Is one system more expensive than three separate products?

It usually costs more to design, because the shared core has to be thought through first. It costs less to run: prices, stock, integrations, security updates and customer data are handled once instead of up to three times. Our starting prices are on the pricing page; the real estimate comes after mapping the business.

Should we use aggregators or build our own delivery?

Many restaurants do both. Aggregators bring reach for a commission, in the US 15% to 30% per delivery order on DoorDash's Marketplace plans as of October 2026, and the customer stays with the platform. Own delivery keeps the customer and the data, and makes the most sense on the same system as the rest of the business.

What should we build first?

The shared core and the channel that already has demand. Map the business, design the catalog, availability, accounts and orders, launch one journey, then add the others and the apps on the same base.

Can we join separate products into one system later?

Often yes, but it is harder than starting with one core. The work is mostly in the data: merging customer lists, matching products across catalogs and moving order history. We start with an audit of what each product holds and decide which parts move to the core and which are rebuilt.

When are separate products the better choice?

When the channels are really separate businesses, when a channel is a short experiment, when the restaurant only needs a menu and booking, or when products, customers and stock do not overlap at all.

Sources

Offered three separate products for one business? Let's look at what your channels really share.

Book a Strategic Session

E-Commerce Development