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 Durable truth

Records and content survive restarts and give the product a place to return to.

Run Plug-in pieces

Runnable pieces can read, transform, render, or answer requests through Bitfield.

Use Any device path

The account decides which runtime identities can trigger Bitfield with your key.

Bitfield should behave like one product surface, not a pile of separate systems you have to manually wire together before you know what you are building. A database stores your data and finds it when you ask. A runtime loads programs and gives them what they need to run. Bitfield does both in one product surface you put inside your app. ## 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](/concepts/database-and-runtime) * Make the first app-facing call: [Quickstart](/start/quickstart) * Build the first screen: [Package to screen](/runtime-kit/package-to-screen) * Check the speed claim: [How Bitfield is this fast](/proof/how-bitfield-is-fast)