Build starts with a product moment: somebody opens a screen, sees real data, presses something, and the product changes without turning your software into a tangled mess.
The Build tab is the map for that moment. Runtime Kit teaches the public primitives. Build shows how those primitives become a product shape you can keep extending.1
Declare the durable records, package-owned files, and callable slots your feature owns.
→
2
Render named data reads and send requests through named public actions.
→
3
Place surfaces in navigation and layout without teaching the shell product logic.
→
4
Run the same product shape across activated devices with account-owned access.
The build loop
| Step | What you decide | Where to go |
|---|---|---|
| Shape the product screen | What the user sees, what data it needs, what actions it can request | App surfaces |
| Shape the package | Which records, package-owned files, and callable slots belong to the feature | Package authoring |
| Shape the target | Which named request changes something or starts work | Target design |
| Shape the shell | Where the surface appears and how the user moves between surfaces | Product shells |
| Shape the rollout | Which devices can run it and what the account/key path looks like | Device and deployment shape |
| Shape another SDK | Which tiny public functions app code should call | SDK boundary |
What this section is not
This section does not replace the Runtime Kit manual. Runtime Kit is the contract layer. Build is the product composition layer.This section also does not ask the shell to become smart. The shell should own placement, navigation, account state, and device state. The package surface should own the feature UI and data it renders. The callable target should own the requested action.Example product path
You are making a small customer dashboard.- The package owns customer records and a package-owned formatter file.
- The surface reads a prepared customer list.
- The surface sends
customer.archivewhen the user archives one customer. - The shell places the surface in a dashboard region.
- The account key activates the runtime identities that can trigger Bitfield.
Common build mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Put product action logic in the shell | Every screen starts depending on one growing layout file | Move the action behind a package target and let the shell place surfaces |
| Read raw package material in app code | The app depends on storage layout instead of a public data name | Use named data reads through the public Runtime Kit surface |
| Make one target do every action | Payloads become a secret command language | Give each product action a named target and a small payload |
| Treat account activation as an afterthought | The build works locally but fails when real devices arrive | Decide the runtime/device trigger path before launch |