Build a web app with the backend included.
Someone signs in, does an hour of work, closes the tab, and opens it a week later to find every record where they left it. That takes a database, a session, and logic that runs on a server. All three arrive with the app.

A complete Orbit-built web app with the launch panel on Prod, the app live on dealroom.orbitapps.ai, and the Pipeline page selected.
How it works
Your app comes with the whole stack.
Every app deploys with its own Postgres, isolated from every other app. Sign-in, server-side workflows, a REST API, and pages that update without a reload all read the same schema, so none of it has to be wired together afterwards.

Sign-in and a Postgres database
The Dealroom app data model, shown as Orbit entity nodes for the backend database.

Server logic and live updates
The Dealroom workflow canvas, showing backend actions connected as live app logic.

An API for the same app
The Dealroom app screen and REST API response using the same backend data.
Sign-in and a Postgres database
Users can log in, stay logged in, and save their data. Each user only sees the data they are allowed to access.
Draw a table and it runs as real Postgres: every field has a type, every link has a direction, and a row that does not match is rejected. Switch on Google or email sign-in, and the database itself decides which rows each person can read.
How the data model works
Sign-in and a Postgres database
The Dealroom app data model, shown as Orbit entity nodes for the backend database.
Server logic and live updates
Workflows run in the background and update your app's data. When data changes, dashboards and queues update automatically without reloading the page.
A workflow runs inside your deployed app, on a schedule or on demand, with your browser shut. It can send through Gmail or Resend, write to GitHub or Linear, or hand a step to Claude or GPT. A failed step retries from a durable queue, up to twenty times.
What a workflow is made of
Server logic and live updates
The Dealroom workflow canvas, showing backend actions connected as live app logic.
An API for the same app
Your app's data model also creates a REST API. That means your screens and integrations use the same data and stay in sync.
Every entity gets GET, POST, PATCH and DELETE under /api/v1, and an OpenAPI 3.0 document at /openapi.json comes off the same schema. Point a client, a codegen tool, or an agent at that document and it reads today's shape.
Where it stops: the API authenticates as the signed-in person, so it is the API behind your app, not a public one with issued keys. Public tokens are on the way.
See the generated API
An API for the same app
The Dealroom app screen and REST API response using the same backend data.
Where it fits
One web app, the whole stack.
Everything ships together: screens, database, workflows, login, and API. You build one complete app instead of connecting separate pieces later.
Build the app and backend together
Describe what users need to do, then compose the screens, sign-in, database and logic into one working app.