HOW IT WORKS
One core. Every surface you need.
Quarkino holds all the logic, data, and security, and exposes it as a documented API. A web storefront, a mobile app, and your team's admin panel all read from the same source of truth — and none of them constrain the others.
It means the back end has no opinion about how anything looks.
Traditional platforms ship the back end and the front end welded together. You get the admin panel and the public site as one thing, and changing how the site looks means fighting the system that generates it.
Headless separates them. Quarkino handles everything behind the scenes — accounts, content, orders, files, permissions, email — and hands it over through an API. What that data becomes on screen is entirely your decision.
Any framework, no permission needed
Next.js, a native mobile app, even a voice assistant — same API. Your frontend team uses whatever they already know.
Product design is unconstrained
The back end makes no visual assumptions, so there is nothing to work around and no theme system to fight.
One back end, many clients at once
A public storefront, a customer mobile app and an internal panel — three separate applications, one truth.
Quarkino is three parts.
Knowing which part does what is the fastest way to understand what you're getting — and what you still need to build.
Quarkino Core
The engine.
Everything that has to be right: business rules, data, authorisation, payments, email, background jobs, integrations. It runs as two processes — an API server that answers requests fast, and a worker that handles anything slow, so a heavy export never slows down someone checking out.
- Documented API, generated from the code itself
- No user interface of its own
- Two processes: fast server, background worker
Quarkino Admin
The control room.
Where your client's team actually works — content, orders, media, customers, reports. The remarkable part: it's generated from the core's own description of itself. Define a new content type, and a working edit form and filterable list appear, with no interface code written for them.
- Screens generated from metadata
- Saved views, bulk actions, global search
- Dashboard widgets each admin arranges themselves
Quarkino Web
Yours to design.
The public-facing layer — the storefront, the site, the app. There is no template to fight and no theme system to learn. It consumes the same API as everything else, in whatever framework your team already knows.
- Any framework
- No design constraints imposed
- One endpoint tells it which features are on and how to brand itself
What happens when someone clicks “buy”.
Five layers, each allowed to do exactly one thing. That constraint is why any of it can be tested.
Route
The request arrives and its input is validated against a strict schema before anything else happens. Malformed data never reaches business logic.
Authorise
Who is this, and what may they do? Permissions are read fresh from the database — never taken from the token, never trusted from the client.
Service
The business logic runs here, and only here. Pricing, tax, stock, discounts — one implementation, used identically by the storefront and the admin panel.
Anything slow leaves here — Email, image processing, reports, translation — handed to the background worker instead of making the customer wait. The response goes back without them.
Repository
The only layer that talks to the database. Which is why each layer can be tested on its own.
Respond
One consistent response shape, success or failure — a stable machine-readable error code, a human message in the right language, and structured detail.
You get what you need. Not what we shipped.
Quarkino's 27 features are a catalogue, not a fixed package. A content-only platform switches the entire commerce module off. A shop switches off the case-management module built for a legal practice.
When a feature is off, it's genuinely gone — its API routes return 404, and it disappears from the menu, from admin search, from bulk actions, and from the dashboard. Not hidden. Absent.
The system also protects the dependency graph: you can't switch on a feature whose prerequisites are off, and you can't switch off a feature that another one still needs. It tells you why, in plain language, instead of breaking quietly.
Being honest about the work that remains.
Quarkino handles
- Accounts, sessions, and security
- Content modelling and publishing
- File storage and image processing
- Catalogue, cart, tax, shipping, orders, invoices
- Email, SMS, and in-app notifications
- Search, reports, import and export
- The admin panel
- Permissions and audit logging
Your team handles
- Design and front-end build
- The workflow specific to this business
- Content and imagery
- Third-party integrations unique to the project
- Deciding which features are on
This column is the part worth paying engineers for.
Let's build the thing you actually want to build.
Tell us what you have in mind. We'll show you how much of it already exists.
- We reply within one working day
- No sales sequence, no drip campaign
- NDA before the call if you'd prefer