The platform · modules

One core. The modules you need.

A business application is not one thing — it is a dozen, badly stitched together, or one suite you take whole whether you use it or not. Moonbase is the third option: a governed core with modules you add as you need them. What you do not install is not attack surface, not upgrade risk, and not an invoice line.

22 modules built · statuses describe what is built, not what is for sale
How to read this page

These are build statuses, not a price list.

The platform has no general availability, no self-service signup and no published pricing — those come later, in that order. “Built” here means the module exists, is tested, and has been exercised by a real customer application rebuilt on the platform. It does not mean you can switch it on this afternoon. When that changes, this page will say so plainly.

Foundation
⬡ Built
Core

Identity, permissions, audit and lifecycle — enforced in the database, so a rule holds no matter which client is talking to it.

◈ Built
Access

Who sees what: roles, teams, delegation and the areas a person lands in when they sign in.

▣ Built
Documents

Generated documents and signatures, with the rendered artefact kept alongside the record it came from.

✓ Built
Approvals

Approval flows with separation of duties enforced — self-approval is blocked by the engine, not by policy.

Commercial
◆ Built
CRM

Accounts, contacts, opportunities and the activity around them.

⬢ Built
Catalog

Products, variants, attributes and price lists — one spine the whole platform prices from.

▤ Built
Quotes & Contracts

Configure, price, quote — through to a signed agreement, with the pricing rules kept honest.

◫ Built
Commerce

Carts, orders and returns, for businesses that sell directly.

◉ Built
Subscriptions

Recurring plans, seats and trials — the lifecycle of a customer who keeps paying.

€ Built
Billing

Invoices, credit notes, VAT and e-invoicing — including the rules that stop a wrong rate reaching a document.

Delivery
◎ Built
Delivery

Projects run on Adaptive Flow Delivery: gates, evidence and decisions, visible while the work happens.

◷ Built
Time

Timesheets and rates, with approval and the billing hand-off built in.

⊞ Built
Funding

Budgets and purchase orders — what a piece of work is allowed to cost, tracked against what it does.

⊕ Built
Service

Cases and a knowledge base, for the part that starts after go-live.

Governance
☑ Built
Compliance

Risks, incidents, controls and GDPR requests — a register that is assessed rather than written once.

⌘ Built
KYC

Know-your-customer checks where a regulator expects them.

§ Built
Agreements

Agreements and their effective dates, so the version in force on a given day is unambiguous.

▦ Built
Tenders

RFx responses and the answer library behind them.

Engagement
⬚ Built
Portal

The place customers and colleagues log in to — announcements, self-service, and the work in the open.

✉ Built
Comms

Multi-channel publishing, from one composed message out to where people actually read it.

◍ Built
Engagements

Meetings, workshops and the interactions worth remembering afterwards.

◐ Built
Feedback

Captures and ideas, triaged into the same backlog the work comes from.

The part that matters

Modularity is a governance property, not a packaging one.

Every module sits on the same core, so permissions, audit and lifecycle behave identically across all of them — a rule written once holds everywhere, and an integration cannot route around a control enforced underneath it. That is the reason to build a platform rather than assemble products, and it is the reason a module you do not install costs you nothing to secure.

Let's talk

Let's build something
worth watching.

Tell us what you're trying to deliver. We'll show you how — gates, visibility and all.

Start a conversation →