Extend and build

Change our apps. Build your own. Same licence, same rules.

Every app we ship is open to extension, and anything you build beside it is a first-class app — same screens, same access engine, same audit trail, same reports. There is no per-app pricing, no add-on catalogue, and no separate development platform to buy.

Three ways in

Extend, customise, or build from nothing

Extend

Add to an app we ship

A field the contract register is missing. A lifecycle state your approvals need. A link from an incident to the asset involved. Additions sit beside our definition, not inside it, so they survive every upgrade.

Customise

Make it read like your organisation

Labels, pick lists, defaults, rules, which fields are required, who is notified. Most of what an implementation project would once have configured is a reviewable change a capable administrator can own.

Build

Create an app that doesn't exist

Describe it to the AI builder or draft it by hand. It lands in your launcher beside ours, reading the same people and organisation tree, governed by the same engine. Nobody has to write code.

How a change happens

Drafted, reviewed, published. Like any other governed record.

  1. Draft

    A change set collects what you want to add or alter — by hand in the builder, or proposed by the AI builder from a description. Drafts are private to their authors until they go for review.

  2. Check

    The compiler checks the draft against the whole system: identifiers unique, rules type-checked, protected core untouched, nothing that would break an existing app. Problems are shown before anyone else sees the change.

  3. Review

    A reviewer sees the change as a document — what is added, what is altered, which apps it touches — and approves or returns it. Who may review is itself a privilege the access engine decides.

  4. Publish

    Publishing is a recorded transition. Screens, API, validation and reports update for everyone at once, and the change is attributable, dated and reversible.

  5. Upgrade

    When we ship a new version of the platform or an app, your changes are replayed on top. Anything that conflicts is shown in a preview before the upgrade, never discovered afterwards.

What you inherit for free

The expensive parts are already done

Access, scoped to the organisation

Declare who may do what in terms of roles and the organisation tree. The engine does the rest, including the scoping that keeps one division out of another's records — and it fails closed.

Evidence and lifecycle

Every record you define gets a lifecycle, an attributable history, effective dating and a reversible "void" instead of a hard delete. Sensitive records can log their reads.

Reports and questions

The moment the app is published, people can ask questions across it and put the answers on a dashboard — trimmed to what each viewer may see. No reporting project follows the build.

Forms, tasks and integration

Public forms that capture into an app from outside, recurring obligations that raise tasks, an API generated from the definition, single sign-on and provisioning through your identity provider.

The honest boundary

What this is for, and what it isn't

It is for the business applications organisations run on — registers, workflows, approvals, obligations, the records behind a process. The kind of thing that lives today in spreadsheets, inboxes and point solutions that do not share a people list.

It is not a way to write your next payroll engine or a consumer product. Where a generated app needs complex computation or bespoke interfaces, the platform's job is to hold the governed data it feeds, and we would rather say so than stretch the claim. How the platform works

Build a practice on it, not around it.

We are looking for implementation partners with domain knowledge in our app families — people who can turn what they know into apps their clients run. What you can deliver is not capped at the apps we ship.