If you have built more than one backend, you know the drill. You create a database schema, scaffold a REST API, add authentication, layer in multi-tenancy, wire up permissions, and deploy to the cloud. The pattern is so repetitive that you could almost automate it.
We did exactly that. And today, we are introducing Apso.
The Problem with Agent-Authored Backends
AI coding tools have gotten good enough to write backends. But there is a problem: the output varies with the model, the prompt, and the day. Two services built a week apart follow different patterns. When the model upgrades, your guardrails silently change. Auditing means reading thousands of lines the agent chose to write, hoping it made the right security decisions.
The issue is not the agent. The issue is where the guardrails live. When security defaults, structure, auth patterns, and multi-tenancy live in a prompt, they are reconstructed probabilistically on every run. Change the model, change the result.
The Determinism Boundary
Apso puts the guardrails in the generator, not the model. You define your data model in a single .apsorc configuration file. Apso then generates a complete backend with CRUD endpoints, authentication, multi-tenancy, database migrations, and deployment infrastructure.
The same schema and CLI version produce the same output on any model.
The agent still drives the process. It can generate the schema, validate it, and iterate on it through the built-in MCP server. The agent's reasoning becomes a reviewable spec, and the generator produces the guarded output from that spec. The agent decides what to build. Apso decides how.
We call this the determinism boundary: the line between nondeterministic agent reasoning and deterministic code generation. Everything above the boundary (intent, schema design, iteration) is the agent's domain. Everything below (structure, security, deployment) is locked in the generator.
What Apso Generates
Define your entities, fields, relationships, and auth rules in .apsorc:
{
"entities": [
{
"name": "Workspace",
"fields": [
{ "name": "name", "type": "text", "length": 255 }
]
},
{
"name": "User",
"fields": [
{ "name": "email", "type": "text", "length": 255, "is_email": true },
{ "name": "name", "type": "text", "length": 255 }
],
"relationships": [
{ "name": "workspace", "type": "ManyToOne", "entity": "Workspace" }
]
}
]
}
Approve the model and Apso generates a complete backend: controller routes, service layer, repository layer, database migrations, error handling, input validation, and deployment config. Apso supports TypeScript, Golang, and Python.
What Makes This Different
Deterministic output. The same schema produces the same output every time. Prompt drift and model dependency do not decide the backend structure. The output is reproducible today, next month, or two years from now on a completely different model.
You own the code. The output is real backend code in your repository. It has no Apso imports, vendor SDK, or proprietary runtime. The generator and templates are open source, and the generated TypeScript, Golang, and Python stacks are open source. Stop using Apso and the code keeps working.
Bring Your Own Auth. BetterAuth, Auth0, Clerk, Cognito, or API keys. Switch providers by changing one line in your schema and regenerating.
Safe regeneration. Generated code lives in src/autogen/. Your custom business logic lives in src/extensions/. Regenerate as many times as you want without losing your work.
Agent-ready. The built-in MCP server lets Claude, Codex, and other MCP-capable coding environments discover and drive Apso without leaving the development workflow.
Getting Started
Connect the Apso MCP server and skills to Claude or Codex. Describe the product, the actors, and the rules that separate their data. Your agent can select a starter backend, adapt the schema, validate it, and generate the service through Apso. You review the model before generation and the normal framework code afterward.
The Apso quickstart covers the connection and first generation workflow.
The agent decides what to build. Apso decides how. Start building at app.apso.cloud.