Every major ERP has an app marketplace. Thousands of add-ons, integrations, and extensions — a thriving ecosystem that makes the platform more capable and the vendor more defensible. We made a different bet: six modules, one architecture, no plug-ins. The constitutional model works only if everything speaks the same language. Here’s the reasoning — and the risk we accepted.
The app marketplace model is dominant in enterprise software for good reasons. It allows the platform vendor to expand functional coverage without building everything internally. It creates an ecosystem of partners who are financially motivated to make the platform successful. It allows customers to assemble the capabilities they need without paying for what they don’t. From a product strategy perspective, it’s a sensible way to build a large platform.
It’s also incompatible with what Nue is trying to do.
Why the marketplace model breaks the constitutional architecture
The Universal Ledger works as a constitutional layer only if every financial event in the system passes through it. Every module — AR, AP, subscription billing, expense management, project accounting, inventory — writes to the ledger under the same rules. The guarantees the architecture produces come from this universality.
An app marketplace introduces third-party modules that, by definition, were built by people who don’t control the ledger layer. A third-party AP automation tool that integrates with Nue doesn’t post directly to Nue’s Universal Ledger through Nue’s enforcement layer — it syncs data through an API, producing exactly the kind of separate-system integration that the constitutional architecture exists to eliminate.
The moment a marketplace app touches financial data outside the ledger layer, the architectural guarantee breaks. The subledger that was a derived view becomes a source that requires reconciliation again. The period controls that were enforced by the database can be bypassed by data coming through the API without going through the trigger. The immutability of actuals can be violated by a third-party tool that writes directly to records after posting.
There’s no partial version of the constitutional model. Either every financial event passes through the ledger, or the guarantees don’t apply to all financial events. An app marketplace makes universal coverage impossible to guarantee.
What this means for coverage
The constraint is real. The six modules Nue ships cover the core — identity and governance, finance and the Universal Ledger, the commercial suite, project management, planning and BI, and media and marketing. They don’t cover everything a large enterprise might want. There are categories — HR and payroll, asset-intensive operations, specialized manufacturing execution — that we haven’t built.
The bet is that the mid-market companies we’re targeting need coverage in the six modules we’ve built, and that the quality of coverage in those modules — because they’re architecturally unified — is more valuable than the breadth of coverage that comes from a marketplace where each module has its own data model.
This is a bet about where value comes from. The marketplace model produces breadth. The constitutional model produces integrity. We’ve chosen integrity, which means accepting scope limits.
The API-first boundary
What Nue does provide is an API layer for external systems that need to interact with Nue data without being part of the constitutional architecture. A payroll system that needs to read employee cost center assignments can do so through the API. A customer-facing portal that needs to surface invoice status can do so through the API. These integrations exist at the boundary of the system — reading data for external consumption or writing data that gets validated by the ledger rules when it comes in.
The distinction is between integrations that consume data (always fine) and integrations that write financial data (must go through the ledger rules). The API enforces this distinction: read operations are available broadly, write operations that affect financial state go through validation that the ledger enforces.
The risk we accepted
There are customers we won’t win because we don’t cover a category they need. A company that requires deep HR integration, or a specific manufacturing module, or a specialized industry function that isn’t in our scope, will choose a different system — probably one with a marketplace that provides the coverage they need, at the cost of the architectural integrity that marketplace precludes.
We made a deliberate decision that this is the right trade-off for the mid-market companies where the constitutional architecture matters most: companies where the finance team is small enough that reconciliation overhead is genuinely painful, where the audit requirements are real, where the CFO needs to trust the numbers rather than validate them. For those companies, six modules that genuinely work together are more valuable than twenty that mostly do.