Headless in plain words: one backend for your site, store and app
What headless means, why it matters when you run a site, a store and an app, and when it pays off for a small business. No jargon.

You have a marketing site, an online store, and maybe you are thinking about a mobile app. Usually each one comes with its own database: customers live in three places, stock in two, and someone copies orders across every evening. “Headless” is the name of a simple idea that fixes exactly that.
What it actually means
Every app has two parts: data and rules (customers, products, prices, orders, appointments) and the interface, meaning what people see on screen.
In a classic platform the two are glued together. A store template comes with its own database, its own design and its own limits. Change the theme and you lose something; want an app and you start over.
In a headless system, data lives in one place and the interface reads it through an API. “Headless” only means the backend does not dictate what the front looks like. You can have as many “heads” as you like: a site, a store, an app, a client portal.
Why it matters for a business
One customer, one record. Someone who buys in the store and then books from the app is the same person, with their full history in one place.
One stock. The web store, the app and in-store sales all draw from the same stock. You stop selling things you no longer have.
Design without limits. The interface is built for your business, not for a template. And it loads fast, because it does not carry features you never use.
Change the interface without moving data. Want a new site in three years? You rebuild it, and customers, orders and content stay where they are.
When it pays off
Headless is not for everyone. It makes sense when:
- you run several channels (site, store, app, portal) and want the same data everywhere;
- you already have an ERP or CRM your team works in and do not want another database;
- you want a design a template will not allow;
- you have your own rules (per-customer prices, resource-based booking, approval flows) that an off-the-shelf platform does not cover.
If all you need is a five-page site and a form, you can start simple. The good part is you can start simple on a headless backend too, and the structure grows with you.
What the backend needs
A good headless backend is more than a database with an API. Look for:
- An API for everything, not just products: customers, orders, invoices, appointments, content.
- Events (webhooks): the site or app learns on its own when a price changes or a booking is confirmed.
- Separate access per channel: a site key reads public content, not invoices.
- Clear documentation, so the team building the interface does not have to guess.
- Content your team can edit, without a developer for every comma.
Want to see how it would look for you?
We will show you how a site, a store or an app connects to the same ERP.
How it works at RIVIL
At RIVIL, the ERP is the backend. Site content is written in the ERP, with your own types and fields (headless website). The store sells from the same catalog and stock (headless ecommerce). Mobile apps and portals work with the same customers (mobile apps, platforms).
And if something is missing, it is built as a new module and shows up in the API on its own. The short version is on the RIVIL Headless page.


