Skip to main content

Gooi

You define your entire application once in a spec: data model, business logic, API surface, access policy, and test scenarios. The compiler validates it and produces deterministic artifacts. At deploy time, you bind providers to capabilities and orchestrate capability changes with deterministic control-plane outputs, without touching your domain logic. The same spec executes across HTTP, web, CLI, and webhooks through the same runtime kernel.

Why this matters

Application behavior is typically distributed across database migrations, route handlers, validation schemas, and test fixtures. No single artifact describes what an application is. This creates four concrete problems:

  1. Business logic is coupled to vendor APIs. Swapping a database or auth provider requires changes throughout the application, not only at the adapter boundary.
  2. Test fixtures drift from production behavior. Tests are written against mocked internals, not the actual execution engine.
  3. There is no canonical description of the application. Onboarding a new engineer requires reading across dozens of files to understand a single feature.
  4. Every adoption depth requires a different mental model. There is no incremental path from "I just want typed contracts" to "I want the full runtime."

Gooi solves all four by making the spec the authoritative source of truth and the compiler the single gatekeeper.

Three pillars

Everything in Gooi fits into one of three developer-facing pillars.

The Spec

The spec is a YAML document that declares your complete application: its data model, business rules, read models, API surface, access policy, and behavioral tests. It compiles. It tests itself. It never references a specific vendor.

Start with The Spec

The Runtime

The runtime executes your compiled spec. You adopt it at the depth you need, from importing typed contracts only (L0) to running the full execution kernel (L3). Each level is independently useful. Moving from L0 to L3 is a series of additions, not a rewrite.

Explore The Runtime

Ecosystem

The Ecosystem covers three workflows in one pillar: binding providers to capability requirements, orchestrating capability changes with control-plane report/plan/apply/drift/generate outputs, and authoring providers/adapters. Missing required support is an explicit failure, not a silent degradation.

Learn about the Ecosystem

Adoption ladder

LevelNameWhat you adoptTime to first value
L0Contract-firstImport GooiAppSpec types only< 10 minutes
L1Compile-firstCall compileApp() in your build< 30 minutes
L2Embedded runtimeCall createAppRuntime() in your server< 1 hour
L3Full platformdefineAppcompileAppcreateAppRuntime< 1 day

Quick Start: get a working spec from zero to first compiled query in under 10 minutes.