For the technical reader. This page describes what’s actually running underneath every application we ship. The rest of the site is intentionally non-technical; this one isn’t.
Foundation
Every engagement runs on a platform we built and operate ourselves. It’s schema-first: define the data model in a declarative configuration, and the platform generates everything that follows.
Out of the box, every app gets:
- Postgres — one logical database per app, with daily backups and point-in-time recovery
- REST API — auto-generated for every model in the schema, with consistent conventions
- gRPC API — same model surface, protobuf-defined
- OpenAPI 3.1 spec — emitted automatically, ready for typed clients, integrations, and AI agents
- Admin UI — generated from the schema; tables, detail pages, filters, search, and audit
- OAuth login — GitHub and Google, with org-scoped membership
Permissions
Permissions are CEL-based and apply at every layer of the platform — row, field, model, and route. Per-org, per-user, and per-role rules compose cleanly. RBAC for the simple case, expression-based policies when you need them.
Operations
- Multi-tenant by design — apps are isolated at the database and runtime level
- Hosted on managed infrastructure (Fly Machines) with health-checked deployments
- Daily Postgres backups, retained on a rolling window
- Dependency and security patching on the platform itself, applied without per-app changes
- A growing suite of regression tests pinned to specific security findings (SSRF, CSRF, upload XSS, tenant isolation, OAuth
email_verified, and more) — once something is fixed, it stays fixed
Building blocks
The schema layer ships with declarative primitives for common application needs:
- File uploads with content-type and size enforcement
- Scheduled jobs and recurring workflows
- Webhooks (inbound and outbound)
- Encrypted fields for sensitive data
- Soft delete with restore
- Imports from CSV and structured sources
- Templated PDF generation
- Notification/messaging channels (email, in-app)
- Custom domains for tenant apps
- Charts and dashboard widgets driven by the same schema
Custom logic
When declarative isn’t enough, apps can run Starlark for business logic — sandboxed, deterministic, and exposed through a stable easy.* stdlib. This is how we ship workflow transitions, computed actions, and custom validations without giving up the safety of a managed runtime.
Limits and non-goals
We’re explicit about what the platform doesn’t do, so a technical reader can decide quickly whether it’s a fit:
- Not a GraphQL backend. REST + gRPC + OpenAPI is the surface.
- Not a real-time / pubsub platform. Webhooks and polling are how data leaves.
- Not a code-generation framework. There’s no per-app build step.
- Not self-hostable today. The runtime is hosted; v2 will revisit this.
If your project’s success depends on something in the non-goals list, we should talk before signing anything — sometimes there’s a clean shape that fits anyway, and sometimes there isn’t.