Composable Development is the construction track. Its governing rule is that every part of the system is either something you wrote or something the platform vendor already guarantees — and nothing in between.
One codebase per platform, written in that platform's first-party language and UI toolkit. No cross-platform runtime, no package manager, no build chain beyond the vendor's own. Startup is fast, upgrades are the operating system's problem, and the whole client can be read.
The backbone is a set of cloud functions, each doing one job against one data shape. A function is small enough to review in one pass, deploy on its own, and reason about without a diagram.
A partition key and a sort key, chosen so the access patterns are known before the table exists. No object-relational layer, no migration framework, no query language between the code and the data.
Every call from a client is signed with short-lived credentials issued to that identity. Authorisation is the platform's, not a library's, and the same mechanism protects every endpoint without a middleware stack.
The central discipline. Before writing a conditional that encodes a product decision, the decision is moved into a key collection and the code is written to read it. What would have been a branch per tier becomes one lookup.
Clients pull the current key collections on a short interval and cache them. A configuration change reaches the entire installed base within one cycle, with no push infrastructure and no coordinated release.
A third-party library enters the system only if it passes all four: the platform vendor does not already provide it; writing it ourselves would take materially longer than adopting it; its abandonment would be survivable; and it does not encode a product decision that belongs in a key collection.
Most candidates fail the fourth test. That is the point — a dependency that makes product decisions for you is a dependency you cannot reconfigure.
Write down every read and write the feature needs before designing a table. The key design falls out of the access patterns, not the other way round.
Identify which parts of the feature are product decisions rather than mechanics. Those become keys. The rest becomes code.
If a rule can be evaluated on the client from a key, it is presentation. If it must be enforced, it belongs in a function. Never both.