Every business application starts the same way: customers, orders, users, roles; a screen to list them, a form to edit them, an API for the website, a log of who did what. Weeks of work that make no business different from the next.

GoatCheese is the generator I build every project with. You describe the business; it writes the plumbing.

The description

A project starts from a schema: a plain-text file listing the things your business deals with, their fields and how they relate. Here is a customer in a small CRM:

"customer('Customer')": {
    with_child_tables: ["contact", "deal"],
    add_search_columns: { "Name": [["name", "%val", "or"]] },
    "id_customer": ["primary"],
    "name('Name')": ["varchar(128)", "required", "unique"],
    "status('Status')": ["enum(lead, active, former)", "default:lead"],
    "email('Email')": ["varchar(320)", "not-required"],
}

That is the whole definition of a customer: its contacts and deals hang off it, it can be searched by name, and a new one starts as a lead. An owner can read it; any developer can review it.

What one build produces

  1. The database. Tables, relations and migrations that only add: a change creates columns and tables, it never silently drops data.
  2. The back office. Menus, searchable lists, edit forms, related records on each page — a customer’s contacts and deals right on its screen — and user and group management.
  3. The API. Every entity reachable over a REST API, behind a login, for your website, a mobile app or an integration.
  4. The access rules. Who can read or change what, derived from the schema, down to “only the records you own” or “only your group’s”.
  5. The MCP server. The connection that lets an AI assistant work with your data — more on that below.
  6. Documentation and tests. An API reference, an entity map and generated tests, rebuilt with the app.

Generated code lives in its own folders and is rewritten at every build. The code that makes your business different — pricing rules, integrations, workflows — lives beside it and is never overwritten.

The MCP: your data, talking to your AI assistant

MCP is the open standard AI assistants use to connect to tools. Every app GoatCheese builds has its own. Add it to Claude as a connector, sign in with your usual login, approve read or write access, and ask: “which deals over $10,000 haven’t moved in a month?”, “add a contact at this company”.

The assistant gets exactly your rights, no more: a record you cannot see in the back office, it cannot see either. Creating or deleting waits for your explicit confirmation, and refused attempts are logged. When a business needs more than records — uploading a document to a knowledge base, say — custom tools sit next to the generated ones.

The checks around it

  • doctor validates a project without building it, so it can run in automatic checks.
  • rbac compares the access rules live in the database with what the schema says they should be, and can tighten any extra to “deny”.
  • verify opens the app in a headless browser, logs in, visits every menu entry and fails on any error.
  • deploy previews every change with a dry run, checks the server, applies only additive database changes and seeds the access rules. Dropping a column needs an explicit confirmation.
  • Logins are throttled after repeated failures, API calls are logged with credentials removed, and a field-by-field change history can be switched on per table.

The numbers

Three applications in production, built this way:

38–85tables per application
200–540access rules, generated
< 1.5 hfrom an empty project to schema, access rules and migrated production data, on a marketplace migration

What stays hand-written is the part worth paying for: between 11,000 and 34,000 lines of actual business logic per application. Everything underneath it is generated, tested and regenerated.

What this means for an SME

Custom software used to mean paying for the plumbing before getting to your problem. With the plumbing generated, the budget goes to the rules, integrations and screens that are specific to you — and you own an application with an API and an AI connection from day one.

And because the description is plain text, it doubles as documentation: the next developer, or an AI assistant, can read what your business is made of in one file.