Not a monolith.A platform.
Most ERP systems in mid-sized companies have grown over two decades: one block, one database, one update date on which everything stops at the same time. fabular is built differently – as a set of services on Kubernetes, with open interfaces, separate storage for different tasks and a dedicated security service in front.
fabular. process chain
Real timeOpen orders
128
Batches today
24
fabAI flagged batch L-2481: three days from best-before – FEFO suggestion created.
- Kubernetes, in our own data centre or in Azure
- REST and MCP instead of a closed interface
- From a handful of workstations to group architecture
The platform in five layers
Each layer can be operated, scaled and replaced separately. That is the real difference to a monolith: it is not the feature list that differs, but what happens when one part grows, fails or has to be replaced.
Access
Everything that reaches the platform
Web interface
Angular application, the same one in the office as in the customer's browser.
Mobile and scanner
Apps for warehouse, delivery and inspection, offline-capable.
Online shop and portal
Included or connected, on the same data.
AI assistants
fabAI inside the system, external assistants via the MCP server, third-party systems via the MCP client.
Security
One gate, one permission model
OAuth 2.1 and OIDC
fabular is an identity provider itself – including for neighbouring applications.
Microsoft 365 and Entra ID
Sign in with the company account, without a second password.
LDAP and directory services
Your existing user management remains the leading source.
Roles instead of full access
Every interface, every agent and every person gets the same kind of permission.
Services
Business building blocks, scalable individually
Service-oriented modules
Purchasing, warehousing, production, invoicing, CRM and more – each building block runs on its own.
fabular.API
REST over HTTPS. What the interface can do, the API can do too.
MCP server and client
Open standard for AI access in both directions, with the same rights and the same logging.
Workflow engine
Processes are configured, not programmed – across module boundaries as well.
Data
The right storage for each task
Relational storage
The accounting truth: documents, stock, postings – transactionally safe.
Vector storage
Contracts, audit reports and manuals searchable by content, the basis for fabAI.
MOLAP cubes
Pre-aggregated figures for analyses that no longer need a night.
Replication
Separate instances for a branch or shop, so that a poor line does not hold up operations.
Operations
Where and how it runs
Kubernetes with SUSE Rancher
In our data centre or in Microsoft Azure – the same platform, your decision.
Containers instead of server maintenance
Roll out, roll back and grow without a maintenance window for the whole company.
New Relic
Runtime monitoring down to the individual request, not only when someone calls.
Separate environments
Test, acceptance and production per customer – changes are checked before they arrive.
The layers are not a diagram for the brochure. In daily operation they decide whether a load peak in the online shop slows down goods receipt, whether an update hits all sites at the same time, and whether a new connection is a project or a configuration.
Eighty per cent is in place before the project starts
The technical base is only half the story. The other half is the business side: fabular consists of a CORE and industry solutions built on top of it. The CORE brings the processes that have to work the same way in every company, the industry solution brings the sector knowledge. Together they cover around eighty per cent of the requirements in our projects – without anyone developing for it.
- Solid financial processes, audited to IDW PS 880 – fabular 4.0.0 with a certificate from May 2026
- Scale communication with a WELMEC conformity certificate – legally verifiable weighing including alibi memory
- Optional operation in a data centre certified to ISO 27001
- Industry solutions from 25 years of project work – batches, recipes, certificates, branch operations
- Available quickly, because it is configured rather than built
- Companies adopt processes that already work elsewhere
~80 %
from CORE and industry solution, without development
~20 %
individual, via fabAI or Vibecoding
25+
years of expertise in the standard
0
shadow systems beside the platform
Where the functions come from
In a custom-built solution almost everything is created in the project – and has to be maintained afterwards. With fabular the large majority is already there and is only set up. The percentages are experience values from our projects, not a commitment.
Custom-built
Every requirement becomes a development order – including maintenance over the entire lifetime.
- Developed in the project
- 80 %
- From the standard
- 20 %
fabular
CORE and industry solution carry the bulk. Development happens only for what actually sets your business apart.
- From CORE and industry solution
- 80 %
- Added individually
- 20 %
This is where – and only where – Vibecoding comes in
What really distinguishes one company from another is in no standard. There are two routes for it, and both stay inside the platform: configured fabAI assistants, or extensions created directly in fabAI.
Dynamically configurable fabAI assistants
An assistant is given a task, the matching data sources and the rights of a role. With that it does what a small add-on program would otherwise do – only without its own program, without its own user management and without its own copy of the data.
Vibecoding directly in fabAI
Extensions are created in dialogue instead of in a specification document and run in the platform straight away. They reach the real data through the existing services, with the same rights and the same logging as any other function.
On an audited base
What matters is what this sits on: audited financial processes, a central permission model, traceable logs. What is created quickly therefore cannot bypass the security or process layer.
What proves itself becomes standard
An extension that turns out to be generally useful moves into the CORE or the industry solution. From then on it is maintained and updated with everything else – instead of remaining a one-off that nobody feels responsible for after three years.
Building fast is easy. Building fast and still being auditable in five years is not.
Vibecoding makes software reachable for people who are not developers. That is a real gain. What is regularly missing is everything that is not visible: audited posting logic, a permission model, logs, data management that survives an audit. That is exactly what fabular brings – which is why we use Vibecoding where it has an effect, rather than everywhere.
- The base is audited, not generated: financial processes to IDW PS 880, WELMEC-compliant weighing, a central permission model
- Individual parts are created quickly, but inside the platform instead of beside it
- No copies of data, no second user list, no access without an expiry date
- What stays becomes standard and is maintained – what goes leaves nothing behind
- Long-term stability for processes that have to carry a company
What happens without a foundation
The first weeks look excellent. Then comes the first audit, the first change of staff, the first question why a figure differs from the ERP – and nobody can answer it, because the logic sits in a tool that nobody ever documented.
Why this rarely comes together
Vendors usually have one or the other: an audited but closed ERP – or an open platform without a business foundation. The combination of a certified core, a ready-made industry solution and AI-supported extension inside the same platform is the point where fabular differs.
A grown monolith next to a cloud-native platform
In the end both systems print the same invoice. The difference shows in operation – under load, during changes, and in everything else that exists alongside.
| The difference | fabularCloud-native, service-oriented | Classic ERPGrown monolith |
|---|---|---|
| Scaling individual areas separately | Instances where the load arises | Only the whole application |
| Updates without downtime | Rolling, with roll-back | Maintenance window for everything |
| Every function reachable via the API | REST and MCP, the same services | Selected exports |
| Separate storage per task | Relational, vector, MOLAP | One database for everything |
| Analysis without a nightly run | Pre-aggregated cubes | Reports run at night |
| Sign-in with the company account | OAuth, Entra ID, LDAP | Often its own user management |
| AI on the real data, with permissions | Via the MCP server | Chat beside the system |
| Operation in your own data centre | Kubernetes, optionally Azure | Usually the normal case |
This is about the way a system is built, not about the vendor. A monolith can be strong in business terms too – it simply behaves differently as soon as one part grows or has to change.
- 1,000+
- ERP workstations in one installation
- 100,000+
- concurrent visitors in the shop
- Seconds
- count during a campaign
Not as a limit, but as operation already reached.
Designed for load peaks from a television spot or a social media post.
Anyone who cannot deliver at the peak loses the revenue to the moment.
When it gets large, and when it is allowed to stay small
fabular runs in a company with fifteen workstations and in group architectures where SAP S/4HANA sits next to it. That is not two products, but the same platform in a different set-up.
- Several thousand ERP workstations in one installation, without the interface becoming sluggish
- Load peaks in retail: a television spot brings hundreds of thousands of concurrent visitors within minutes
- Horizontal scaling: additional instances come up when the load rises, and go again
- Integration instead of replacement: as a specialised platform beside a group SAP landscape with S/4HANA
- Multi-company and multi-site operation, including replication and offline operation at the till
- Proven, not calculated: the orders of magnitude come from live installations
Scaling does not mean buying
In a monolith more load means a bigger server. On Kubernetes instances are added for as long as they are needed, and disappear again afterwards. That changes the cost curve, not just the technology.
Beside SAP, not against SAP
In groups, financial authority often stays with S/4HANA. fabular then takes over the areas for which a group solution is too coarse – batches, recipes, certificates, branch operations – and delivers the results back.
Measuring instead of guessing
Through New Relic we see which request takes how long, before anyone calls. When a campaign is planned, the system is load-tested beforehand rather than explained afterwards.
What sits behind the terms
For everyone who wants to know it more precisely – without marketing in between.
Cloud-native, not cloud-hosted
The difference is not where the application runs, but how it is built: containerised, largely stateless, horizontally scalable, with health checks and rolling rollouts. A monolith in a cloud VM remains a monolith.
Service-oriented
Business building blocks with their own interfaces instead of one interwoven code base. A building block can get its own resources, run its own versions and fail without taking the whole down with it.
REST services
JSON over HTTPS, the same services our own interface works with. No second, cut-down set of interfaces for outsiders – what works on the inside works on the outside too.
MCP
Model Context Protocol, an open standard for access by AI assistants to business systems. The platform is both: a server for assistants from outside and a client for the MCP servers of your other systems. Sign-in via OAuth 2.1 with PKCE, rights as for a user, every access traceable.
Relational storage
Microsoft SQL Server for everything posting-relevant: transactions, referential integrity, backup and restore following an audited policy.
Vector storage
Documents are converted into embeddings and become searchable by content. That is what allows fabAI to answer a question about a contract without anyone knowing the file name.
MOLAP
Multi-dimensional, pre-aggregated cubes instead of reports recalculated every time. Revenue by region, period and product group comes from the cube, not from a nightly run.
Central identity provider
fabular can act as the OAuth and OIDC provider for neighbouring applications. Self-built tools and integrations sign in there instead of keeping their own user lists.
WELMEC and legally verifiable weighing
WELMEC is the European cooperation in legal metrology. Where a weight is the basis for a price, a tax or a record, the software between scale and document has to work demonstrably correctly. A conformity certificate exists for our scale communication, and weighing runs with an alibi memory – every weighing can be reconstructed later.
Observability
New Relic across the whole chain, plus health checks and metrics per service. A problem becomes visible before it reaches daily operations.
Why this matters for self-built tools
In many companies small applications are now being created beside the ERP – clicked together, generated with AI, for one specific purpose. That is a good thing, as long as they do not fail on user management or create their own copy of the data.
- Your own application signs in with fabular instead of keeping a second user list
- It gets exactly the rights its role has – no more, and traceably
- It reads and writes through the fabular.API, so it works on the same data
- If the tool is dropped, nothing remains except a deactivated account
- The same applies to AI agents via the MCP server
This is the core of Beyond Vibecoding
Quickly built tools are a gain, as long as there is a system beneath them that carries processes, rights and records. That is exactly the role fabular has.
Where it otherwise tips over
Without central access you get copies of data in spreadsheets, accounts without an expiry date and analyses that nobody can retrace. That rarely shows up immediately, but reliably at the audit.
On the technology
Do we have to go to the cloud?
No. The same platform runs on Kubernetes in our data centre, in Microsoft Azure or in your own cluster. The decision depends on your requirements for data storage, availability and operations staff – not on the product. The AI functions are no reason to send data out of the building either.
What does Kubernetes actually deliver day to day?
Three things. First: updates run rolling, operations do not stop while they do. Second: if the load grows in one place, instances are added there, not everywhere. Third: a crashed service is detected and restarted before anyone writes a ticket. These are not fine points for IT, but the difference between a maintenance window and a running business.
How reliable are the figures for large installations?
They come from live systems, not from an extrapolation. For a specific plan, though, the number of workstations is only half the answer – what matters is what those workstations do. We go through this with your processes and load-test the system beforehand if a campaign is coming up.
Does fabular replace our SAP?
Not necessarily, and often that is not the aim at all. In groups, financial authority usually stays with S/4HANA. fabular then takes over the operational areas for which a group solution is too coarse or too expensive to adapt, and returns the results. In mid-sized companies, by contrast, fabular is regularly the leading system.
What happens to our data if we stop?
You get it. The relational storage is a standard database, not a proprietary format, and everything visible in the interface can be read out through the fabular.API. That belongs in the contract, not in a promise.
Let us talk about your architecture
Bring your system landscape – how you operate, your load profile, what is meant to stay. We will tell you how fabular fits in there and where the effort lies.