Built in production.
Proven at scale.
dbo.io has been running in production environments for 15 years. Here's what that looks like in practice.
One application. The full enterprise.
An enterprise operations team needed a complete business platform — one that could handle payments processing, inventory management, payroll, customer account management, and data warehousing across a distributed organization.
What was built
A single dbo application manages the majority of this organization's business operations. None of these capabilities were built into dbo — they were built as dbo applications, using the schema definition, security model, API surface, and automation framework that dbo provides.
- Payments processing — transaction handling and reconciliation
- Inventory management — product catalog, stock levels, supplier management
- Payroll — employee records, compensation, scheduling
- Operational access — hundreds of employees access the same system daily
- Customer account management — millions of customer records
- Data warehousing — intelligence aggregation, automated reporting, backup processing
- Bank reconciliation — automated background processing against financial transaction data
- Financing — customer financing workflows integrated with the operational data model
Why dbo was the right choice
The organization needed a platform that could evolve as the business grew without accumulating technical debt. When a new workflow was required, a new entity or output was defined. When a security requirement changed, a security record was updated. The middle tier never needed to be rebuilt because there was no middle tier.
The platform runs in the client's own VPC. Source code is provided under the client agreement — not because dbo needs to be modified, but because a system this central to operations requires the option of independent maintenance if it's ever needed.
iOS. macOS. Web. AI. One dbo app.
Queue is a social link-sharing application: users save links, organize them into lists, share lists with collaborators, and pull items into their reading queue. It has a dedicated iOS app, an iOS share extension, a macOS app, a web application, and an MCP (Model Context Protocol) server for AI assistant integration.
Every client — iOS, macOS, web, and AI — accesses the same dbo-generated API.
What was not written
No API controllers. No routing logic. No ORM or data access layer. No custom authentication system. No separate backend code for iOS vs. web vs. macOS.
The Queue application is its schema, its output definitions, its security records, and its content templates. That is the entire server-side codebase.
The data model
The MCP server
Queue ships with an MCP server that exposes its dbo-generated API to AI assistants (Claude, ChatGPT, Cursor, and any other MCP-compatible client). AI assistants can query lists, add items, manage sharing, and interact with the full Queue data model through structured tool calls — using the same API endpoints that the iOS and web clients use, subject to the same security model.
Queue demonstrates what a modern, cross-platform application looks like when built on dbo.io. The breadth of clients — native iOS, native macOS, web, and AI agents via MCP — all served by a single API generated from a single data model — is the clearest possible demonstration of the platform's value proposition.
The platform runs on itself
Operator is the dbo.io management console — the application developers and administrators use to configure entities, manage outputs, define security rules, edit content, set up automation, and manage app versions. Operator is itself a dbo application.
Why this matters
Every capability that Operator uses to manage a dbo application — querying entities, writing records, rendering content, enforcing security — is the same capability available to any application built on dbo. There is no privileged internal API, no bypass path, no special sauce underneath the hood. If the framework is good enough to run its own management console in production, it is good enough to run your application.
What Operator manages
Every capability the dbo.io API provides has a corresponding UI in Operator: entity editor, query editor, content editor, security manager, media manager, messaging configuration, automation/scheduler, integration manager, version and release management, and full revision/audit trail viewer with rollback.
Operator as a frontend OS
Beyond managing the dbo.io platform itself, Operator is a frontend operating system framework for running third-party dbo applications as workspaces and widgets. Developers build dbo applications and deploy them into Operator as workspaces. Employees or end-users then run those applications inside the Operator shell — without the development team having to build a custom navigation system, routing layer, application container, or UI framework from scratch.
What's coming: PlotOS
The frontend framework embedded in Operator is being extracted as a separate open-source project called PlotOS — a client-side runtime that turns structured data descriptions into fully functional web applications. PlotOS is backend-agnostic; it works with any backend that returns structured data, not just dbo.io. Once extracted, PlotOS will be freely available for any developer to use.
Build and deploy dbo apps without leaving your editor
The dbo CLI integrates with Claude Code — Anthropic's AI coding environment — to enable fully AI-assisted dbo development. Install the CLI plugin once, and every Claude Code session on that machine gains /dbo-push, /dbo-pull, and /dbo-clone slash commands.
dbo install plugins --globalWhat this enables in practice
- Ask Claude to create a new output (named query) for a specific data view, push it to the server, and verify it returns the expected data — in one conversation
- Make edits to content templates, security records, or entity definitions by describing the change in natural language; Claude writes the change to the local file and pushes it
- Clone an existing app, explore its structure, make modifications, and push the changes without writing a single CLI command manually
- The
CLAUDE.mdfile at the project root gives Claude persistent context about the app's conventions, data model, and current state
Why dbo is a natural fit for AI-assisted development
Because dbo applications are structured metadata — not imperative code — AI models can read, reason about, and modify them reliably. A content record, a security rule, an output definition — these are JSON structures with known schemas. Claude does not need to trace control flow or understand side effects. It reads a record, understands the structure, and produces a valid modification.
Every change is tracked in the revision system. Every push is logged. No action is permanent without _confirm=true.
Building and managing a dbo application becomes a conversation. Describe the schema change, the new feature, the security adjustment. The AI handles the API calls and file operations. The developer reviews, approves, and moves on. This is not a niche workflow — dbo applications are actively built and maintained this way.
Ready to stop writing the middle tier?
dbo.io is invite-only. We work with a small number of early partners to make sure the integration is set up right. Tell us about what you're building.