a composable framework

Build less.
Own all of it.

Three decades of methodology added tiers, then frameworks, then frameworks on top of frameworks — each layer added to manage the complexity of the one beneath it. Aurora Composable removes the layers instead of managing them.

two techniques

One framework, two tracks.

They are deliberately separable. Adopt the first alone and you get a smaller, more durable codebase. Adopt both and you can change what the product does without changing the product.

ZERO
third-party frameworks between your code and the platform

A framework is a set of decisions someone else made, delivered as code you now maintain.

the shape

Three parts, no fourth.

Anything that does not belong to one of these three does not belong in the system.

01 — the client

Renders state, captures intent

Written in the platform's own language and UI toolkit, with no dependency tree. It holds no business rules of its own, so it rarely needs to change.

02 — the backbone

Runs the operations

Small single-purpose functions over a key-value store, reached through signed endpoints. No application server, no ORM, no framework runtime.

03 — the key collections

Hold the decisions

Who may do what, what runs when, what gets recorded, how the product behaves. Data, read at runtime by the client and the backbone alike.

the stack

Your app on top. The platform underneath.
Composable tech in between.

The app and the cloud platform are the two fixed points — you own one and rent the other. Everything that decides how the product actually behaves lives in the layer between them, and that layer is data.

the two fixed points
App framework Managed services Keys permission lifecycle transaction behavior privilege key key key key key key key key key key key key key key key key key key key key key key key key key key key key key key Lifecycle what runs, and how often Policy who may do what, and how much Platform services Composable tech Platform
why it matters

What the shape buys you.

01

Change without release

Tiers, limits, entitlements and feature switches are configuration. They move in minutes, for every installed client at once, with no store review in the path.

02

A codebase that stays small

Behaviour that would otherwise become branches becomes rows instead. The code that reads a key collection is written once and then stops growing.

03

No inherited upgrade debt

There is no dependency tree to keep current, no framework major version to migrate to, and no upstream project whose abandonment becomes your emergency.

04

Portability by construction

Two clients on two platforms read the same key collections and behave identically, because the behaviour was never written into either of them.

Most systems hide their decisions inside code.
A composable system publishes them as data.