Write what your business needs in one readable file. Bever turns it into a validated, authorized API and a working web app, on defaults you can replace. Your team reads it, your AI writes it, and nothing hides in the plumbing.
A real model, typed change by change. Each change compiles, and the app follows it.
The problem
A rule as simple as "signed-in people may change a task's status, and the status is To do, In progress, or Done" ends up spread across a controller, a validator, a migration, a form, client types, and the tests that keep them in step. Nobody can point to where the rule lives, so every change is a search, and every search can miss a copy.
A typical stack
TasksController.cswho may call itTaskValidator.csthe allowed values20261028_AddStatus.csthe column and its defaultTaskForm.vuethe select optionsapi/types.tsthe client's copy of the shapeTaskTests.csthe checks that they still agreeBever
Entity Task
Field Status Enum(ToDo, InProgress, Done) = ToDo
Action Crud Task
By AuthenticatedOne place to read, one place to change. The server enforces it, the database migration follows it, and the app shows it.
Coding agents spend most of their effort reading and rewriting boilerplate. With Bever, a feature is a few lines in a .bev file. The server and the app read the compiled model, so the agent has nothing else to keep in sync.
Add a priority to tasks, Normal by default.
Entity Task
Field Title Text(200)
Field Status Enum(ToDo, InProgress, Done) = ToDo
+ Field Priority Enum(Low, Normal, High) = NormalThe API validates it, the migration adds the column with a value for existing rows, and the list and forms show it.
The agent reads and writes a model of a few dozen lines instead of controllers, forms, and migrations. Smaller context, smaller output, lower cost.
A feature is a short change to one readable file, not a pull request across twenty. You see the business change, not the wiring.
The compiler rejects mistakes with file, line, and column. The server checks every permission, whatever the agent wrote. Destructive migrations wait for your consent.
bever new picks a stack so you can start in minutes: Nuxt for the app, SQLite for the data, and ASP.NET Core for the server. None of it is locked in. The model is the contract, and every layer around it is a default you can change.
The default, and how to change it
@bever/sdk or the HTTP APIIBeverDatabaseProviderclient/Validation and permissions run in the server, whatever client or database you use. A replacement decides where data is stored or how it looks, never whether a request is allowed.
client/ and server/ are ordinary projects in your repository, and Bever comes in as packages. Replace one page and the model still drives the rest.
The compiled model is JSON in a documented format, so your own tools and scripts can read it too.
Every action names who may perform it. The server checks every request, filters lists to what each person may see, and rejects values that do not match their type.
Lists with search and sorting, forms with validation, relationship pickers, sign-in, dark mode, and a phone layout.
Schema changes become reviewed migration files. Destructive changes need consent, and new required fields need a value for existing rows.
client/ is a normal Nuxt app and server/ is a normal ASP.NET Core app. Change any page, component, or endpoint; Bever stays a library.
A .bev file says what the business needs and nothing about how a framework wires it up. Product owners can read it.
The language, compiler, runtime, and tools are Apache 2.0. A project created with bever new is entirely yours.
Four commands give you a task app with sign-in, projects, and tasks, running locally.
dotnet tool install --global --prerelease Bever.Cli
bever new "Acme Tasks"
cd "Acme Tasks"
bever dev
