SIMPLE POWERFUL CLIENTS
Native front ends built with the platform's own tools and nothing else. No dependency tree, no bridge layer, no build chain to keep alive. The client renders state and reports actions — it does not carry the business.
Three decades of methodology have added tiers, then frameworks, then frameworks on top of frameworks. Each layer was added to manage the complexity of the layer beneath it. Aurora Composable removes the layers instead of managing them.
What is left is a client that renders, a backbone that runs, and a body of configuration data that decides what both of them do.
Native front ends built with the platform's own tools and nothing else. No dependency tree, no bridge layer, no build chain to keep alive. The client renders state and reports actions — it does not carry the business.
A cloud backend assembled from primitives — functions, tables, identity, storage — with no third-party framework between the code and the platform. Fewer parts to upgrade, patch, license and explain.
The intelligence of the system lives in key collections rather than in branches. Permissions, lifecycle, transactions, behaviour and privilege are all expressed as data that the running system reads.
Changing what the product does is a configuration change, not a release. Tiers, limits, entitlements and timings move in minutes, and they move for every client at once without an app store in the path.
Every dependency removed is a dependency that cannot break, cannot be abandoned upstream and cannot force an unplanned migration. Low clutter is not an aesthetic preference — it is the maintenance budget.
The framework is not theoretical. It is drawn from a live consumer product and its backend ecosystem — mobile clients on two platforms, a cloud backbone, and the key collections that drive both.
Aurora Composable is practised along two tracks. Composable Development is how the software is built: the shape of the client, the shape of the backbone, and the discipline of keeping third-party framework code out of both. Composable Behavior is how the software is run: rapid configuration of what the product does, for whom, and under what limits — expressed entirely in data.
The tracks are deliberately separable. A team can adopt the development track alone and gain a smaller, more durable codebase. A team that adopts both gains the ability to change the product's behaviour without changing the product.
Most systems hide their decisions inside code. A composable system publishes them as key collections — permissionkeys, lifecyclekeys, transactionkeys, behaviorkeys, privilegekeys and bespoke keys — which the client and the backbone both read at runtime.