Bitfield is a database and a runtime that runs on any device.
You have an idea, then the idea changes. You add a phone screen, a laptop dashboard, a background job, a file, a local mode, and a friend who wants to try it. The hard part is not writing the first feature. The hard part is keeping feature one from trapping feature one hundred.Store
Records and content survive restarts and give the product a place to return to.
+
Run
Runnable pieces can read, transform, render, or answer requests through Bitfield.
+
Use
The account decides which runtime identities can trigger Bitfield with your key.
Why it exists
The usual way of building makes you pick a database, a framework, deployment, sync, offline behavior, files, background jobs, and device strategy before you know what the product will become.That works until the product changes. Then every new feature starts depending on old features. One edit turns into ten.Bitfield changes the dependency pattern. Every feature uses Bitfield’s public names instead of directly importing every other feature.The term ladder
Database.
The durable side. It remembers records and content.
Runtime.
The runnable side. It loads the pieces that do work.
Runtime Kit.
The app-facing package. Your app reads named data and sends named requests through it.
Slot.
A named package target your app can ask to do work. Your app calls the public slot name, not the private implementation.
Package.
A product boundary that can declare records, package-owned bytes, and callable targets.
Active device.
A device or runtime identity that triggered Bitfield in the billing window.
What this prevents
| Wrong shape | Why it breaks later | Bitfield shape |
|---|---|---|
| Every feature imports every other feature | Changes spread through the product | Features use public names and requests |
| The UI owns storage details | Screens become hard to move | Runtime Kit gives the UI named data and targets |
| Device access is an afterthought | Trials, phones, laptops, and friends get confusing | Active devices are part of the account path |
| Speed claims are read as universal magic | Readers compare unlike jobs | Proof pages name measured categories |
The point
You get structure without giving up speed. You can start small and keep adding pieces without making every feature depend on every other feature.Next
- Understand why database and runtime belong together: Database and runtime
- Make the first app-facing call: Quickstart
- Build the first screen: Package to screen
- Check the speed claim: How Bitfield is this fast