Bitfield products are not only pages. They run through runtime identities that send request bytes to Bitfield, with local state, account-owned access, and product packages that should keep working as your idea changes.
In this page, runtime identity includes cloud and local shapes. A laptop, server, worker, kiosk, or CI runner can all count when they actually send request bytes to Bitfield during the billing window.You start with a laptop and phone. Then a friend tests it. Then ten customers use it. The product shape should not change just because the device count grows.Account
The customer creates an account and receives access through the account portal.
→
Device
Each device or runtime identity sends request bytes to Bitfield when it needs runtime access.
→
Product
The product reads local Bitfield state and uses packages/surfaces/targets.
Deployment questions
| Question | Why it matters | Page |
|---|---|---|
| How does the user get a key? | The product cannot run without account access | Get your key |
| How many devices can try it first? | Trial shape affects first customer experience | Trials and billing |
| What will actually be charged? | Runtime/device units are identities that send Bitfield request bytes, not visitors, page views, projects, or packages | What you pay for |
| Where does local state live? | Users need to understand ownership and no-hand-edit boundaries | Local state |
| Which package runs the feature? | Product behavior should stay package-shaped | Package authoring |
| Which surface appears first? | The first visible result sells the product path | App surfaces |
Rollout shape
Start by proving the product moment on one device. Then invite more devices without changing the product architecture:- Keep the package file stable.
- Keep the surface read/request contract stable.
- Keep the shell placement contract stable.
- Let account/device access decide who can run it.
Hosted and static output
A hosted product can send Bitfield request bytes from a server. That server runtime identity can count for the billing window.A public static page is different. Visitors reading ordinary hosted output send no Bitfield request bytes. Keep marketing pages, docs pages, pricing pages, and other public read-only pages static when they do not need live Bitfield data or Bitfield requests.That is not a workaround. It is the clean deployment shape. Use Bitfield where the product needs Bitfield, and do not pay for runtime where static output is enough.Common failures
| Symptom | Cause | Fix |
|---|---|---|
| Works on one machine only | Local state and account activation were not part of the build path | Add the key/device path to the launch checklist |
| Users hand-edit local state | Docs or UI did not explain ownership | Link to local-state boundaries and expose product controls |
| Every device needs a different feature build | Product package and shell placement are tangled | Separate package, surface, target, and shell concerns |
| Public visitors look like runtime units | Static pages and live Runtime Kit surfaces were mixed together | Keep public read-only pages static and use Runtime Kit only where Bitfield request bytes are needed |