Most business applications start as CRUD.
Create a record.
Edit it.
Delete it.
Show it in a list.
That works well at the beginning.
But serious business software usually does not stay that simple.
When CRUD stops being enough
CRUD is a good starting point for simple data management.
But in real business applications, records often become business documents.
And a business document is not just a row in a table.
It can have:
- status;
- lifecycle actions;
- business meaning;
- audit history;
- related documents;
- reportable consequences;
- traceability requirements.
An invoice is not only a row.
A lease is not only a row.
A payment is not only a row.
An inventory movement is not only a row.
These documents represent business intent.
Actions matter
In a CRUD application, the main operations are usually:
- create;
- read;
- update;
- delete.
In business software, the important operations often look different:
- post;
- approve;
- apply;
- complete;
- close;
- reverse;
- trace.
These actions are not just UI buttons.
They represent business boundaries.
An action may create durable effects. Depending on the document and the vertical, those effects may include Operational Register movements, Reference Register changes, Accounting entries, audit history, document relationships, reporting state, or any combination of them.
Sometimes a posted document may create no register or accounting movements at all.
For example, a lease can be posted because the business state itself is meaningful, even if it does not create accounting or register movements at that moment.
That is an important distinction.
Posting is not the same thing as “creating accounting entries”.
Posting is a business lifecycle boundary.
Reports need traceability
Another place where CRUD starts to break down is reporting.
In many systems, reports become disconnected from the source documents that created the numbers.
That creates a problem:
A user sees a number, but cannot easily understand where it came from.
In serious business applications, reports should not be dead ends.
A report should stay connected to:
- source documents;
- business actions;
- durable effects;
- registers;
- audit history;
- related records.
That traceability is part of the architecture, not just a UI feature.
Why I’m building NGB Platform
This is the gap NGB Platform is built for.
NGB Platform is an open-source .NET + PostgreSQL platform for document-driven business applications.
The core idea is:
Documents represent business intent.
Actions create durable business history.
Reports should stay connected to source documents.
NGB is not a low-code CRUD generator.
It is also not only an accounting platform.
It provides a reusable foundation for business applications built around catalogs, documents, lifecycle actions, Operational Registers, Reference Registers, Accounting, audit history, reporting, metadata-driven UI, and vertical demos.
The goal is to make the hard parts of serious business software reusable.
Links
GitHub: https://github.com/ngbplatform/NGB
Website: https://ngbplatform.com
Docs: https://docs.ngbplatform.com
YouTube video: https://youtu.be/bgMmbLHz3M8