DEV Community: NGB Platform

https://github.com/ngbplatform/NGB/releases/tag/v3.0.0

NGB Platform v3.0.0 release:

Documentation:

https://docs.ngbplatform.com

Tags: dotnet, opensource, architecture, postgresql

NGB Platform v2.0: Document Actions + Work Center

NGB Platform — Tue, 18 Aug 2026 13:15:00 +0000

NGB Platform v2.0: Document Actions + Work Center

NGB Platform v2.0 introduces two closely connected capabilities:

Document Actions
Work Center

The goal is simple: connect what can happen to a business document with the work users actually need to perform next.

Document Actions

Document operations are now exposed through a single backend-driven action model.

For every document, the backend determines:

which actions the current user is allowed to see;
whether an action is currently available;
why an action may be disabled;
how the action should be executed.

The frontend no longer needs to duplicate these rules.

Document Actions are also not limited to lifecycle operations such as:

Post
Unpost
Repost
Mark for Deletion

The same model can represent derivations, navigation actions, and view actions.

For example, a CRM Lead Intake can expose Create Lead Qualification as a normal Document Action.

Work Center

The second part of the release is the new Work Center.

Work Center brings together two different concepts:

Tasks — business work that still requires action.
Notifications — information that the user should know about.

They are intentionally separate models, but presented through one attention queue.

The badge in the application header is therefore not simply an unread notification count.

It represents:

open actionable tasks + unread notifications

A task remains actionable even after the user has opened or read it.

From Lead Intake to actionable work

The video uses a CRM flow to demonstrate how these two capabilities work together.

A Lead Intake is posted.

That business event creates a task for the Sales team:

Qualify Lead

The task is available in Work Center and is connected to its source document.

If the task is assigned to a role, an eligible user can claim it.

From Work Center, the user executes Create Lead Qualification.

This is not a special Work Center command. It is the same Document Action infrastructure used by the document itself.

The user completes the Lead Qualification and posts it with a Qualified result.

At that point, the original task is completed automatically.

The important part is that nobody manually checks a box saying that the task is finished.

The underlying business state determines that the work has actually been resolved.

And the next task appears:

Convert Lead

The process continues through the same model.

Tasks represent business state

This distinction is important.

Opening a task does not complete it.

Reading a task does not complete it.

Claiming a task does not complete it.

The task stays active until the business condition behind it is resolved.

That makes Work Center different from a traditional notification list.

It represents actionable business work, not just messages about things that happened.

Keeping the Platform generic

Work Center itself does not know what a Lead Intake, Lead Qualification, or Lead Conversion means.

The CRM vertical owns those business rules.

The Platform provides the reusable infrastructure:

Document Action definitions and execution;
permission and availability evaluation;
user and role task assignment;
claiming and snoozing;
tasks and notifications;
automatic task lifecycle based on business events;
attention tracking;
the compact Work Center drawer;
the full Work Center page;
in-app notification preferences.

This keeps vertical-specific business behavior outside the Platform while still giving every vertical the same infrastructure to build on.

NGB Platform v2.0

The main idea behind this release can be summarized in two lines:

Document Actions define what the user can do next.

Work Center shows what actually needs attention next.

Together, they connect document operations with actionable business work.

Watch demo:

https://youtu.be/2l_7sQvYfJs

Source code:

https://crm-demo.ngbplatform.com

NGB Platform v1.3.1: CRM Demo Built with NuGet and npm Packages

NGB Platform — Sun, 12 Jul 2026 16:54:47 +0000

NGB Platform v1.3.1 is released.

This release is an important milestone for the project because it shows something I wanted to prove from the beginning:

NGB is not a single vertical application.

NGB is a platform for building vertical business systems.

The new CRM demo is not intended to be a Salesforce replacement or a full CRM product.

It is a demonstration of how a completely different business vertical can be built on top of NGB Platform using published packages.

Live demo:

Release:

https://github.com/ngbplatform/NGB/releases/tag/v1.3.1

GitHub repository:

https://github.com/ngbplatform/NGB/releases/tag/v1.3.1

What changed in v1.3.1

The main highlight of this release is the new NGB CRM demo.

But the more important part is how it was built.

The CRM demo consumes NGB Platform as packages:

NGB.Platform.* NuGet packages
@ngbplatform/ui npm package

That means the CRM demo does not need to clone the platform source projects directly.

This is a major step for NGB because it moves the project closer to a real platform model:

platform core
published backend packages
published UI package
vertical applications built on top

Why CRM?

Previous NGB demos were closer to traditional business and ERP-like domains:

Property Management
Trade
Agency Billing
Accounting and reporting scenarios

Those demos are useful, but they can create the wrong impression.

It may look like NGB is only about accounting-heavy systems.

That is not the goal.

NGB is designed for business applications in general:

catalogs
documents
lifecycle actions
posting semantics
reference registers
operational registers
accounting registers
reports
auditability
metadata-driven UI

Some verticals need accounting.

Some do not.

CRM is a good example of a vertical that can use the NGB model without using the accounting engine at all.

CRM demo without accounting

The CRM demo does not use the accounting engine.

It also does not use operational accounting-style movements.

That is the point.

The demo is built around CRM concepts:

accounts
contacts
products
opportunity stages
lead intake
lead qualification
lead conversion
opportunity updates
quotes
activity logs
sales pipeline reporting
activity reporting
quote register reporting
lead conversion funnel

The CRM flow is document-driven.

A lead is captured as a document.

Qualification is a document.

Lead conversion is a document.

Opportunity updates are documents.

Quotes are documents with reusable product lines.

Activities are documents.

When documents are posted, they update read-side projections through reference registers.

Reports are built from those projections.

So even without accounting, the same NGB platform ideas still apply:

source documents → posting boundary → register projections → reports

Why packages matter

Before this release, it was possible to build verticals inside the repository.

That is useful for development, but it is not enough to prove a platform.

A real platform should be usable from the outside.

With v1.3.1, NGB now has public package families:

NuGet packages for backend platform capabilities
npm package for the UI framework

This makes the platform boundary much clearer.

A vertical solution can depend on NGB Platform packages instead of directly depending on platform source projects.

That is important for several reasons.

First, it validates the public API surface.

If a vertical can only work by referencing internal source projects, the platform boundary is not real yet.

Second, it makes versioning more meaningful.

A vertical can target a specific platform version.

Third, it makes the project easier to understand.

Developers can look at CRM as an example of how to consume NGB Platform rather than digging through the entire platform implementation first.

Current live demos

NGB now has multiple live demos:

Property Management: https://pm-demo.ngbplatform.com
Trade: https://trade-demo.ngbplatform.com
Agency Billing: https://ab-demo.ngbplatform.com
CRM: https://crm-demo.ngbplatform.com

Each demo shows a different type of vertical application built on the same platform foundation.

Final thoughts

The CRM demo is intentionally not a full CRM product.

That is not the purpose.

The purpose is to show that NGB Platform can be used to build vertical business applications of different types and different complexity levels.

With v1.3.1, NGB takes an important step toward that platform model:

published packages, reusable UI, and a new vertical built as an external consumer.

Release:

Repository:

User Roles & Permissions for Business

NGB Platform — Tue, 23 Jun 2026 13:05:33 +0000

NGB v1.2.0 is now available.

This release adds user roles, permissions, and application-level access management to NGB Platform.

The core idea is simple:

Keycloak handles identity.
NGB handles application access.

Why this matters

Authentication and authorization are not the same thing.

Authentication answers:

Who is this user?

But a business platform also needs to answer:

What is this user allowed to do inside the application?

For simple apps, this can often be hardcoded.

For serious business applications, that does not scale.

Users have different responsibilities.
Different departments need different access.
Some users should only view data.
Some users can create drafts.
Some can post documents.
Some can run reports.
Some can export data.
Some can manage other users and roles.

That is why NGB v1.2.0 adds application-level access management as a platform capability.

Keycloak for identity, NGB for application access

NGB does not try to replace Keycloak.

Keycloak remains responsible for:

authentication
SSO sessions
external user identity
enabled / disabled identity-provider users

NGB is responsible for:

application roles
permission assignments
effective access
permission-aware metadata
menu and report filtering
backend permission checks
security audit records

This separation is intentional.

Keycloak owns identity.
NGB owns business application access.

What was added in v1.2.0

This release adds:

NGB-managed roles and permissions
user management
role assignment
permission definitions
permission matrix
effective access snapshots
access-version invalidation
permission-aware UI surfaces
backend-enforced access checks
Keycloak Admin integration
security audit foundations

The first vertical wired with this model is the NGB Property Management demo.

It includes seeded roles such as:

PM Administrator
PM Accountant
PM AR Clerk
PM AP Clerk
PM Property Manager
PM Maintenance Coordinator
PM Auditor
PM Read Only

These are not just UI labels.

They map to concrete permissions across documents, catalogs, reports, accounting tools, admin pages, audit access, and other platform surfaces.

Effective access

One important part of this release is effective access.

A user can have multiple roles.

NGB combines those roles and shows what the user can actually access.

That makes administration easier because you can answer questions like:

Can this user execute this report?
Can this user export report data?
Can this user manage roles?
Can this user access audit information?
Can this user post a specific document type?

This is especially important for business software, where permissions are not just technical details. They are part of the operating model of the company.

Permission-aware UI, but backend as the source of truth

The UI is now permission-aware.

Menus, document metadata, catalog metadata, reports, command palette entries, admin pages, and actions can be filtered or disabled based on the current user's access.

But the UI is not the security boundary.

Backend checks are still enforced by the runtime.

Hiding a button improves the user experience, but backend authorization is what actually protects the application.

Why this is a platform feature

NGB is a document-driven business application platform.

That means access control cannot be implemented as a one-off feature for one screen or one demo.

Documents, catalogs, reports, accounting tools, operational registers, reference registers, admin pages, and vertical-specific features all need a consistent authorization model.

That is what this release starts to provide.

NGB v1.2.0 is an important foundation for production-oriented vertical business applications where users do not all have the same access.

Links

Documentation: https://docs.ngbplatform.com/

Release: https://github.com/ngbplatform/NGB/releases/tag/v1.2.0

Video: https://youtu.be/zaW638VhoT8

Reference Registers in NGB Platform: Effective Business State Over Time

NGB Platform — Thu, 18 Jun 2026 13:08:46 +0000

In many business applications, reference data starts simple.

An item has a price.
A contract has terms.
A rate has a value.
A customer has settings.

At first, it feels natural to store this as one current value.

But serious business software usually needs more than the current value.

It needs to know what value was effective at a specific point in time.

The problem with one mutable current value

Imagine an item price.

If the price changes today, should old documents suddenly look like they used the new price?

Usually not.

A sales document created last month should be able to use the price that was effective last month.

A report should be able to explain which price was active on the report date.

A new document should use the currently effective price.

That is hard to model if the system only stores one mutable current_price field.

When the value changes, history becomes harder to explain.

What are Reference Registers?

In NGB Platform, Reference Registers track effective reference state over time.

They are not Operational Registers.

They are not Accounting entries.

Reference Registers answer a different question:

What value, rule, status, or relationship was effective at a specific point in time?

Examples can include:

item prices;
rates;
contract terms;
assignments;
statuses;
rules;
configuration values.

In the Trade vertical, the clearest example is item pricing.

Example: Item Price Updates in Trade

In the Trade vertical, item prices are changed through an Item Price Update document.

The document contains:

effective date;
item;
price type;
currency;
unit price.

When the document is posted, it writes Reference Register rows.

Those rows represent the effective item price state.

The important part is that the previous value is not silently overwritten.

A new value becomes effective from a specific date.

Current Item Prices

The Current Item Prices report reads from Reference Register state.

It can show the effective price by:

item;
price type;
currency;
effective date;
source document.

That gives the system a clear answer to a practical business question:

What price is currently effective for this item and price type?

But the system still keeps the history behind that answer.

Why this matters for documents

A Sales Invoice should not just guess a price from a mutable field.

It should be able to use the price that is effective for its context.

That context may include:

document date;
item;
price type;
currency;
customer or other vertical-specific dimensions.

This is why Reference Registers are useful.

They make reference state time-aware, durable, and explainable.

Reference Registers are not Operational Registers

Operational Registers track operational movements and balances.

For example:

inventory increased;
inventory decreased;
quantity was consumed;
balance changed.

Reference Registers track effective reference state.

For example:

this item price is effective from this date;
this rate applies from this date;
these terms became effective from this date.

Both are important, but they solve different problems.

Reference Registers are not Accounting

Accounting tracks financial ledger effects.

Reference Registers do not replace accounting.

They answer a different question.

Accounting says what financial entries were created.

Reference Registers say what reference value, rule, or state was effective at a point in time.

In NGB Platform, Operational Registers, Reference Registers, and Accounting are peer platform capabilities.

A document action can create:

Operational Register movements;
Reference Register changes;
Accounting entries;
any combination of them;
or none of them.

Why Reference Registers matter

Reference Registers help avoid a common problem in business software:

Important business values are treated as mutable fields, and history becomes unclear.

With Reference Registers, the system can preserve time-aware business state.

That makes documents, reports, and future actions easier to explain.

The core idea

The core idea is simple:

Reference Registers track effective business state over time.

In the Trade vertical, that means item prices can change through source documents, become effective from specific dates, and remain available for reports and document processing.

That is one of the reasons NGB Platform is built around documents, actions, durable effects, and traceable business state.

Links

Video: https://youtu.be/Ej0iDW3zyic

Operational Registers in NGB Platform: Tracking Operational Business State

NGB Platform — Tue, 16 Jun 2026 13:03:26 +0000

Most business applications eventually need to track more than documents.

A purchase document is not only a form.

A sales document is not only a row in a table.

A business action can change operational state:

inventory available;
quantity consumed;
customer balance;
resource usage;
allocation;
operational progress;
reportable state.

That is where Operational Registers come in.

What are Operational Registers?

In NGB Platform, Operational Registers are used to track durable operational business state.

They are not accounting entries.

They are not just audit logs.

They answer a different question:

What changed in the business operation?

For example:

how many units are available?
how much quantity was consumed?
what balance changed?
which resource was allocated?
what state should be available for reports or future business actions?

Operational Registers are about operational truth.

Why not store this directly on the document?

A document stores business intent and context.

For example, a purchase document can say:

We received these items into this warehouse.

A sales document can say:

We sold these items to this customer.

But operational state should not be hidden only inside mutable document rows.

If inventory availability, balances, usage, or progress are stored only as fields on documents, the system becomes harder to explain and harder to report on.

Instead, a posted document action can create durable Operational Register movements.

That gives the system a separate, reportable history of what changed.

Example: purchase and sale

In the Trade vertical, a purchase document can increase inventory.

A sales document can decrease inventory.

The documents represent the business events.

The Operational Register rows record the operational effects.

A simplified example:

Purchase Invoice → +10 units
Sales Invoice    → -3 units
Available stock  →  7 units

The important part is not just the final number.

The important part is that the number can be explained through durable movements.

Operational Registers are not Accounting

Operational Registers are separate from Accounting.

Accounting tracks financial ledger effects.

Operational Registers track operational movements and balances.

A sale may create accounting entries, but it may also change inventory, quantities, allocations, usage, or other operational state.

Those are different concerns.

Putting every business effect into accounting would be wrong.

Not every business document is financial.

And not every business effect belongs in accounting.

Operational Registers are not Audit Logs

Operational Registers are also separate from audit history.

Audit history answers questions like:

who did something?
when did they do it?
what action was executed?

Operational Registers answer questions like:

what quantity changed?
what balance changed?
what operational state is now available?
what can reports and future actions rely on?

Both are useful, but they solve different problems.

OR, RR, and Accounting are peer capabilities

In NGB Platform, Operational Registers, Reference Registers, and Accounting are peer platform capabilities.

Operational Registers track operational movements and balances.

Reference Registers track effective reference state over time.

Accounting tracks financial ledger effects.

A document action can create:

Operational Register movements;
Reference Register changes;
Accounting entries;
any combination of them;
or none of them.

That flexibility matters because different vertical business applications need different kinds of durable business state.

Why Operational Registers matter

Operational Registers make business software easier to reason about.

They make operational state:

durable;
reportable;
explainable;
reusable by future actions;
separate from accounting;
separate from audit history.

This is especially important in document-driven applications where business actions create consequences that should outlive the document form itself.

The core idea

The core idea is simple:

Documents describe business intent.
Actions create durable business history.
Operational Registers record operational movements and balances.

That gives NGB Platform a reusable way to model operational truth across different vertical business applications.

Links

Video: https://youtu.be/Ra54WlrXSJU

Document Action Effects Report: How NGB Models Business Flows

NGB Platform — Thu, 11 Jun 2026 13:59:43 +0000

Most business applications start as CRUD.

Create a record.
Edit it.
Delete it.
Show it in a list.

That works for simple data management.

But serious business software usually needs a different model.

A business document is not just a row in a table.

It represents business intent.

Document → Action → Effects → Report

In NGB Platform, a business flow starts with a document.

The document can represent an invoice, a lease, a payment, an order, or another business event.

The important part is that the document has business meaning before and after the user acts on it.

Then the user executes a business action.

In NGB, documents can move through actions such as:

Draft;
Post;
Apply;
Mark for Deletion.

These actions are not just CRUD operations.

They represent business boundaries.

Actions create durable business history

A business action may create durable business history.

Depending on the document and the vertical, that history may include:

Operational Register movements;
Reference Register changes;
Accounting entries;
audit history;
document relationships;
reportable state.

But not every document creates every kind of effect.

Some documents create several effects.

Some create one.

Some posted documents create no register or accounting movements at all, but still represent an important business boundary.

That distinction matters.

Posting is not the same thing as “creating accounting entries”.

Posting is a document lifecycle boundary.

Effects depend on the document

In NGB, Operational Registers, Reference Registers, and Accounting are peer platform capabilities.

A document action may produce movements in any combination of them.

Or it may produce no register/accounting movements at all.

The platform should not force every document into the same shape.

A lease, an invoice, a payment, and an operational document can all have different consequences.

The important part is that the system preserves the business meaning of the action.

Reports should stay connected to the source

Reports should not be disconnected from the documents and actions behind them.

When users see a number, status, or result, they should be able to understand where it came from.

That means reports should stay connected to:

source documents;
business actions;
durable business history;
register movements;
accounting entries when they exist;
audit history;
related records.

This traceability is part of the architecture, not just a UI feature.

The core idea

The core idea behind NGB Platform is simple:

Documents represent intent.
Actions create durable business history.
Reports stay connected to the source.

That is why NGB is built as a document-driven business application platform on .NET and PostgreSQL.

It is not a low-code CRUD generator.

It is not only an accounting platform.

It is a reusable foundation for building vertical business applications with catalogs, documents, actions, Operational Registers, Reference Registers, Accounting, audit history, reporting, metadata-driven UI, and traceability.

Links

YouTube video: https://youtu.be/ua44kdbpszA

Why CRUD Is Not Enough for Serious Business Apps

NGB Platform — Tue, 09 Jun 2026 13:02:15 +0000

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

YouTube video: https://youtu.be/bgMmbLHz3M8

Testing NGB Platform Beyond a Small Demo Dataset with k6 and TypeScript

NGB Platform — Wed, 20 May 2026 14:54:09 +0000

I recently released NGB Platform v1.1.1.

The main addition is the first NGB Performance Tests Framework.

This is not just a set of endpoint benchmarks.

NGB Platform is an open-source, metadata-driven business platform for building accounting-first industry solutions. The goal is not to build isolated CRUD applications, but complete business applications where documents, catalogs, accounting, audit history, workflows, reports, and background processes are part of the same architecture.

So performance testing has to follow the same idea.

It needs to test real platform behavior, not only isolated HTTP latency.

Why performance testing matters for NGB

In many applications, performance testing starts with a few simple endpoint checks.

That can be useful.

But it does not answer the most important questions for a business platform.

For NGB, the important questions are different:

Can users browse documents while other users are posting documents?
Can reports stay usable as data volume grows?
Can audit history remain readable under pressure?
Can accounting effects be opened quickly after posting?
Can document flow stay responsive?
Can the platform preserve business correctness while handling mixed read/write workloads?

NGB is accounting-first.

That means a posted document is not just a saved record.

It can produce:

Accounting entries
Audit records
Document relationships
Reportable business effects
Operational state changes

So performance testing has to cover business workflows.

Not just endpoints.

What was added in v1.1.1

NGB v1.1.1 adds a dedicated performance testing workspace based on:

Grafana k6
TypeScript
Reusable scenario profiles
Keycloak tester authentication
Custom metrics
Thresholds
Vertical-specific workload packages

The repository now includes:

performance-tests/
  ngb-performance-tests-framework/
  ngb-property-management-perf/
  ngb-trade-perf/
  ngb-agency-billing-perf/
  scripts/

The most important part is the boundary.

The shared framework is vertical-neutral.

It knows platform concepts:

Auth
Health
Metadata
Catalogs
Documents
Reports
Accounting effects
Document flow
Audit
Scenarios
Metrics
Thresholds

It does not know Property Management, Trade, or Agency Billing.

Vertical packages define their own document types, catalog types, report IDs, fixtures, and workload mixes.

That separation matters.

I do not want performance testing to become another place where platform and vertical layers start leaking into each other.

The first serious validation run

For the first serious validation run, I used the NGB Property Management vertical.

The environment was intentionally local:

Local Docker deployment
PostgreSQL database around 19GB
Around 1.7M business documents
Around 27M audit log records

This is not a third-party audited benchmark.

It is not a claim of unlimited scale.

But it is an important production-readiness signal.

NGB is no longer tested only as a small demo dataset.

It now has repeatable performance workloads running against real platform behavior and non-trivial data volume.

What was tested

The performance framework includes multiple workload profiles.

Some of the important ones are:

Smoke
Baseline
Platform read
Platform reporting
Platform read capacity
Platform mixed capacity
Platform breakpoint
Document lifecycle
Audit
Maintenance
Concurrency
Business day
Write-heavy

The goal is not to run all of them every time.

Different profiles answer different questions.

Platform read capacity

This profile focuses on read-heavy platform behavior.

It helps validate whether common read paths stay stable under high concurrency.

Platform mixed capacity

This is one of the most important profiles.

It combines different types of platform activity instead of testing only one endpoint.

The workload includes document reads, platform reads, reporting, audit-related operations, accounting effects, document flow, and other common application behavior.

Write-heavy

This profile is more aggressive.

It exercises document create/update/post operations while the system is also reading accounting effects, audit history, document flow, and reports.

For an accounting-first platform, this is one of the most important scenarios.

Writes are not just writes.

They create durable business consequences.

Selected results

Here are selected results from the run set.

Mixed capacity

The mixed-capacity profile ran for around 80 minutes.

Results:

9.5M+ requests
1,000 peak virtual users
0 dropped iterations
0 business failures

This matters because the workload was not a single endpoint benchmark.

It exercised mixed platform behavior under sustained load.

Read capacity

The read-capacity profile pushed read pressure higher.

Results:

10.8M+ requests
1,400 peak virtual users
0 dropped iterations
0 business failures

The important signal here is the combination of request volume, concurrency, and correctness.

Not just one latency number.

Write-heavy workload

The write-heavy profile ran document lifecycle operations under pressure.

Results:

1.75M+ requests
Document create/update/post activity
Accounting effects reads
Audit reads
Document flow reads
Report execution under write pressure
0 dropped iterations
0 business failures

This is the kind of workload that matters for NGB.

The platform needs to stay usable while documents are being created, posted, audited, explained, and reported on.

What I look at

For this framework, one metric is not enough.

I care about several signals together:

HTTP failure rate
Business operation failure rate
Dropped iterations
p95 latency
p99 latency
Checks
Thresholds
Report execution behavior
Operation-level breakdowns
Document post latency
Accounting effects latency
Audit latency
Document flow latency

A good result is not just:

The test finished.

A good result means:

No silent business failures
No dropped iterations for the target profile
No broken checks
No hidden vertical coupling in the shared framework
No report path that only works on a tiny dataset

For business software, performance is not only speed.

It is also correctness under pressure.

Why this matters for architecture

NGB is built around several platform-level ideas:

Documents represent business intent

Business operations are modeled as documents, not random database updates.
Posting creates durable effects

Posted documents can create accounting entries, audit records, operational state, and reportable business consequences.
Auditability is part of the platform

The system should explain what happened and why.
Reports are connected to business truth

Reporting is not just a separate dashboard layer.
Verticals extend the platform

Property Management, Trade, and Agency Billing should reuse the same platform capabilities without duplicating the core engine.

The performance framework follows the same architecture.

The shared framework tests platform concepts.

Vertical packages provide vertical-specific workloads.

That is the same boundary the runtime architecture is supposed to preserve.

What this does not claim

I want to be precise about the result.

This does not mean:

NGB has been certified by an external benchmark
NGB has unlimited scale
A local Docker run is the same as a production Kubernetes deployment
Every possible workload has been tested

That would be an overclaim.

What it does mean is more practical:

NGB is now tested beyond a toy demo dataset.

It has repeatable performance workloads for real platform behavior.

It can validate documents, posting, audit, accounting effects, document flow, reports, and mixed read/write scenarios against meaningful data volume.

That is a much stronger foundation than only saying:

It works on my machine.

Links

GitHub:

https://github.com/ngbplatform/NGB/releases/tag/v1.1.1

Release:

Performance tests workspace:

https://github.com/ngbplatform/NGB/tree/main/performance-tests

Documentation:

https://docs.ngbplatform.com

Website:

https://ngbplatform.com

Final thought

Performance testing business software is not only about latency.

It is about confidence.

Confidence that the platform can preserve correctness under pressure.

Confidence that reports still work when data grows.

Confidence that audit history and document flow remain usable.

Confidence that posting does not become a black box.

NGB v1.1.1 is an important step in that direction.

The platform is no longer validated only by functional demos.

It now has a reusable performance testing framework for real business workloads.

That is the kind of foundation I want for building serious accounting-first business applications.

NGB Reports: Canonical + Composable Reporting on .NET and PostgreSQL

NGB Platform — Tue, 12 May 2026 13:19:53 +0000

I just published a new demo of NGB Reports — the reporting layer of NGB Platform.

NGB Platform is an open-source, metadata-driven business platform for building accounting-first industry solutions. The goal is not to build isolated CRUD applications, but complete business applications where documents, catalogs, accounting, operational registers, audit history, workflows, and reports are part of the same architecture.

This demo focuses specifically on reporting.

Why reporting matters in business applications

In many business systems, reporting is added late.

The application starts with forms, tables, documents, and workflows. Then, at some point, users need visibility:

What happened?
Which documents created accounting entries?
What is the current balance?
Which invoices are still open?
What is the profitability by project?
Can I drill down from a report number to the source document?

If reporting is treated as a separate dashboard layer, it often becomes disconnected from the real business model.

For NGB, reporting is a first-class platform capability.

Reports need to understand the same metadata, document model, accounting structures, and navigation patterns as the rest of the application.

What the demo shows

The video walks through reporting inside the Agency Billing vertical, but the reporting engine itself is platform-level and reusable across different NGB-based industry solutions.

The demo covers:

Canonical accounting reports
Composable business reports
Report Composer
Grouping
Filters
Fields
Sorting
Report variants
Drilldowns from reports to source documents
Document-aware reporting
The reporting architecture behind the platform

Canonical reports vs composable reports

NGB Reports supports two important reporting models.

Canonical reports

Canonical reports are predefined reports with strong business semantics.

Examples include accounting reports such as:

Trial Balance
Balance Sheet
Income Statement
Cash Flow Statement
General Journal
Account Card
General Ledger
Ledger Analysis

These reports are not just generic grids. They represent known accounting/reporting concepts and can have specialized execution logic, validation rules, paging strategies, and drilldown behavior.

Composable reports

Composable reports are more flexible.

They allow users to configure:

Row groupings
Column groupings
Visible fields
Filters
Sorting
Aggregations
Variants

This is useful for business-specific reports such as unbilled time, invoice registers, project profitability, aging reports, and operational summaries.

The goal is to provide flexibility without turning the system into an unstructured reporting sandbox.

Report Composer

One of the main parts of the demo is the Report Composer.

The Composer allows users to configure report layout and behavior directly from the UI:

General parameters
Grouping
Filters
Fields
Sorting
Variants

The important design goal is that the frontend is metadata-driven. The UI does not need to hardcode every report layout manually. The backend provides report definitions and presentation metadata, and the frontend renders the report experience consistently.

This keeps the platform extensible as new verticals and reports are added.

Drilldowns and document-aware reporting

For business users, numbers in reports should not be dead ends.

If a report shows a balance, invoice, account, project, or document-related value, the user should be able to navigate to the underlying source.

In the demo, reports can drill down into source documents and related business records. This is especially important for accounting-first applications because users often need to trace a number back to the document or posting that produced it.

This is one of the areas where reporting becomes tightly connected to the platform architecture.

Reports are not only about displaying data.

They are also about explainability.

Architecture direction

NGB Reports is designed around a few principles:

Metadata-driven definitions

Reports are described by definitions and presentation metadata, instead of being hardcoded page by page.
Reusable platform engine

The same reporting infrastructure can be reused across different verticals.
Canonical + composable model

Some reports need strong predefined semantics. Others need flexible user composition.
Document-aware navigation

Reports should connect back to documents, catalogs, accounts, and business entities.
Production-oriented execution

Reporting needs to handle paging, validation, stable execution paths, and performance considerations from the beginning.

Tech stack

NGB Platform is built with:

.NET
PostgreSQL
Vue
Metadata-driven architecture
Kubernetes-oriented deployment practices

The reporting engine is part of the broader NGB Platform architecture, which includes documents, catalogs, accounting, operational registers, reference registers, audit history, background jobs, and vertical-specific business modules.

Links

Video demo:

https://youtu.be/euqMDpjEcsM

GitHub: