What you are actually buying, described plainly.
A Site of your own, all eighteen applications inside it, and a team that operates the boring parts so you never have to think about them.
Five layers, one instance.
Read from the top down and the whole product fits on one page.
Your Site
A Site is one company's instance of the whole suite. It has its own database, its own file storage, its own users, its own configuration and its own address. Every application you switch on runs inside it. Nothing about it is shared with another customer except the machines underneath, and on the larger plans not even those.
The application layer
All eighteen applications are installed into your Site as one deployment. They are not separate services glued together over an API, which is why a sales order can write a stock movement and a ledger entry in the same transaction rather than three systems eventually agreeing.
The data layer
One database per Site. One customer record, one item master, one chart of accounts, one employee record. Reporting reads the same tables the applications write, so a report cannot be stale relative to the system it describes.
The agent layer
The AI agents run alongside the applications with a permission context borrowed from the user who invoked them. They read live records at the moment of the request, act through the same validation rules a person would hit, and retain nothing afterwards.
The platform layer
Provisioning, updates, backups, monitoring and billing. This is the part we operate so you do not have to hire someone to operate it. It is also the part that makes a new Site appear in minutes rather than in a project.
The reason it is one deployment and not eighteen services.
A suite assembled from separate products has to keep them in agreement. That agreement is maintained by synchronisation, and synchronisation fails: a webhook is missed, a retry doubles a record, a nightly job runs while an invoice is mid-flight. Every integrated stack has a person whose informal job is knowing which system to believe.
When the applications write to the same database in the same transaction, that class of failure does not exist. A shipment cannot exist without its stock movement. An invoice cannot disagree with the order behind it. There is no reconciliation job because there is nothing to reconcile.
The cost of that design is that you cannot swap one application for a competitor's. We think that is an honest trade, and we say it out loud rather than discovering it with you later.
Our own infrastructure in Europe, Germany and the Netherlands. No data replicated outside the EU.
One database and one file store per Site. Separation at the storage layer, not by a filter in a query.
TLS 1.2 and 1.3 only in transit, with modern cipher suites. At rest, storage dedicated to your Site inside European data centres with physical access control.
Dedicated queues per Site for scheduled jobs, imports, emails and agent tasks, so a heavy neighbour cannot slow your evening reports.
Targeted at 99.9 percent monthly, excluding announced maintenance. Live status is published.
Recovery point of 24 hours on daily backups, with shorter windows available on the larger plans.
From the day it is created to the day you leave.
Including the last one, which most vendors leave out of the diagram.
Provisioning
A Site is created from a known-good template: database, storage, scheduler, workers, certificates and DNS. Minutes, not days, and identical every time, because a manual step is a step that eventually gets done differently.
Updates
Applied in a maintenance window you can see in advance. Updates run against a copy first and roll back automatically if the migration does not complete cleanly. You are never asked to schedule an upgrade project.
Backups
Daily full backups with the database and files together, retained on separate infrastructure in Europe. Restores are tested, because a backup nobody has restored is a hypothesis rather than a backup.
Monitoring
Availability, queue depth, job failures, disk and response times, watched continuously. Most incidents are noticed and handled before a customer writes in, which is the entire point of watching.
Scaling
More resources are a plan change rather than a migration. Your data does not move, your address does not change, and nothing needs reconfiguring on your side.
Exit
Full export of the database and all files, in open formats, whenever you ask, at no charge. We would rather compete on being worth keeping.
Architecture questions.
Is this multi-tenant or single-tenant?
Single-tenant data, shared operation. Each Site has its own database and its own file storage. On Starter, Sites share machines under strict per-Site resource limits. From Growth upwards a dedicated application environment is available on request, and from Scale upwards dedicated database capacity as well.
Can we host it ourselves?
Larger customers can have a private deployment on infrastructure dedicated to them, which we still operate. We do not licence the platform for you to run entirely on your own, because a system nobody operates properly is worse for you than one we watch.
What happens during an incident?
The status page is updated first, before an explanation exists, because silence is the worst part of an outage. Affected customers get direct notification, and anything material gets a written post-incident note describing what happened and what changed as a result.
How do you avoid one customer affecting another?
Resource limits per Site on CPU, memory, storage and queue workers, plus separate background workers. A runaway import in one Site consumes that Site's allowance and nobody else's.
What is the update cadence?
Regular small updates rather than annual releases. Security fixes go out immediately. Feature updates arrive continuously and are announced in advance where they change behaviour rather than add to it.
Do we get a test environment?
Yes. A staging Site can be created from a copy of your production data from the Growth plan upwards, which is the correct place to try a configuration change before it reaches the people doing the work.
