Desktop app for macOS, Windows and Linux
From data model to backend.You own the code.
Declare collections, columns and routes — in the editor or by asking the AI agent; the backend lands as source files on your disk, in the stack of the pack you install.
- Local install: the project sits in the folder you pick
- Free account, no password: e-mail code, GitHub or Google
- Modeling and generating need no paid plan
numberstringtotaldecimalpaidbooleancustomer_idstring
AI agent
The agent models and generates the code. You approve every diff.
It calls the same editor operations. No code reaches your disk without your sign-off.
- 1
I need invoices with line items, linked to the customer.
- 2
Two collections, one relation and a listing route.
- 3
Applied. Both collections are in the module tree.
- 4
8 files to write. No existing file gets overwritten.
- 1
You ask in plain language
One sentence, the way you would tell a teammate.
- 2
It proposes the model
It reads the pack manifest before proposing.
describe_project
- 3
It applies through the editor
The same calls the interface makes.
create_collectionadd_columncreate_relationset_route
- 4
You approve the diff
Generation arrives as a diff. You read and approve.
generate
Runs on whichever AI provider you configure — including a local one.
What you build
The editor speaks domain, not backend
Collections, columns, relations and routes fit any system with data. The four below are models; the pack you picked generates their backend.
Sales and relationships
Customers, what is in the pipeline, and the history of every talk.
4Collections you declare
customerdealactivitynote
Inventory and catalog
Products with variants, where each one sits, every movement on record.
4Collections you declare
productvariantwarehousestock_movement
Scheduling
Who attends, what they offer, and what is already booked.
4Collections you declare
professionalserviceappointmentavailability
Internal portal
People, departments, and the requests that need approval.
4Collections you declare
employeedepartmentrequestapproval
None of the four ships ready-made: they are example models. What ships ready is the pack’s generator, which turns what you declared into code.
Four parts, and the vocabulary comes from the pack
Declarative modeling
Collections, columns and routes become versioned JSON inside the project.
Generation with diff approval
Nothing reaches your disk without a diff you approve.
An agent that drives the editor
It calls the editor’s own operations instead of improvising architecture.
Signed packs
The stack, the vocabulary and the generator come from the installed pack.
From model to disk
You declare the collection. The backend shows up as files.
Nothing hidden between the screen and the disk: the editor saves this file, and this is the file the generator reads.
What you declare
Planuze's collection editor, with a sample collection open.
numberstringtotaldecimalpaidbooleancustomer_idstring
The file the editor saves
planuze/api/invoice/schema.json
{ "schemaVersion": 1, "id": "invoice", "name": "invoice", "columns": [ { "id": "c1", "name": "number", "type": "string", "unique": true }, { "id": "c2", "name": "total", "type": "decimal", "precision": 12, "scale": 2 }, { "id": "c3", "name": "paid", "type": "boolean", "default": false }, { "id": "c4", "name": "customer_id", "type": "string", "indexed": true } ], "relations": [ { "id": "r1", "name": "customer", "kind": "many-to-one", "target": { "kind": "collection", "id": "customer" }, "fkColumn": { "kind": "column", "collectionId": "invoice", "columnId": "c4" }, "targetColumn": { "kind": "column", "collectionId": "customer", "columnId": "c1" } } ], "routes": [ { "id": "rt1", "type": "index", "enabled": true }, { "id": "rt2", "type": "store", "auth": true, "enabled": true } ]}What lands in your project
- schema
Database schema, in the language of the pack’s ORM.
- migration
Versioned migration, from the current state to the new one.
- model
Typed model, with relations already resolved.
- validator
Input validator, derived from each column’s rules.
- controller
Controller carrying the operations of the configured route.
- route
Route registration in the API, ready to take a request.
Plain files on your disk: opens in your editor, goes into your commit, runs with Planuze uninstalled.
From the download to these files
- Sign in with an e-mail code, GitHub or Google. A plan and an AI provider can wait.
- Install a pack and create the project: you pick the folder on your disk.
- Declare the collection and ask for generation: you read the diff, approve it, and the files show up in the folder.
No lock-in
The generated code is yours, and stays yours if you leave
Ordinary source code, with dependencies you already know. There is no layer of ours between your backend and your production.
On your disk, from the very first file
Generation writes into the directory you picked. No upload, no cloud workspace.
Versionable like any other code
Declarative files and generated code go into the same commit. Diff, blame and revert work.
You ship it your way
Container, VM, serverless, whatever pipeline you already run. No infrastructure of ours to go live.
Leaving breaks nothing
Uninstall it and the project still compiles and runs. You lose the tool, not the product.
What is not in the way
- No proprietary runtime in production
- No mandatory call to a server of ours for the backend to work
- No closed format — the declarative files are readable JSON
- No database lock-in: the pack picks the ORM, and you pick the pack
Packs
The stack is not our call — the pack declares it
A signed bundle carrying an entire stack. The editor and the generator both come out of its manifest; the core holds no opinion on any stack.
declarationsThe manifest is the vocabulary
A pack declares which column types, relations, routes and validators exist. Without that list the editor builds nothing.
signatureAlgorithmSigned, and checked before it installs
Manifest and content lock arrive signed with Ed25519, one SHA-256 per file. Missing signature or unverified key: refused.
stackA different stack is a different pack, nothing more
Language, database and ORM come from the installed pack’s manifest, on one line of it. The core carries no route type and no column type name — switching stacks means installing another pack.
distributionShipping your own is the same road, reversed
You generate the key pair, then bundle and sign through the CLI — the private key never leaves your machine. The registry re-checks before the catalog.
The pack catalog lives inside the app and changes over time. Price and access for each one are resolved by your license, at install time.
Organizations
An organization is not a shared login
Each person has their own account and their own seat. Every administrative action is recorded with an author and a date.
- Three roles, settled on the server
- Owner, admin and member. Every action goes through the server’s permission matrix, and there is no automatic membership by email domain.
- Included seats, and extras per seat
- Contracting above the included count charges the difference on the spot; lowering it becomes credit on the next invoice. The owner’s seat holds the license and cannot be released.
- Packs only your organization can see
- A pack of the organization is visible only to whoever you authorize. Leave and the access leaves with you: membership is checked on every listing and every download.
- A record of who did what
- Invitation, member removal and ownership transfer are stored with author and date, in the same transaction. The trail exports to CSV or JSON.
People, seats and the audit trail live in the organization panel, inside Planuze itself — with no separate web portal.
Where your data sits, and what the app sends out
Four facts about where things live, plus the full inventory of what leaves your machine and the reason for each trip.
The project lives in the folder you picked
You point at a directory and Planuze writes into it: declarations, each collection’s schema, and the generated code. The agent’s history sits under the app’s data folder, also on your machine. There is no cloud workspace.
Keys go to the operating system keyring
API keys, the license token and refresh tokens live in a vault encrypted by Electron’s safeStorage — Keychain, DPAPI, libsecret. With no keyring available, the production build fails rather than writing anything in the clear. The app window stores no secret.
You pick the AI provider, a local one included
Anthropic, OpenAI, Gemini, Ollama, or any endpoint that speaks the OpenAI API. With Ollama the inference runs on your machine, with no key and no network. With a remote provider, the app talks straight to its API with your key, and no proxy of ours in between.
There is no usage analytics
No product SDK, no behavioural events, no usage metrics — taken out of the app, and this page carries none either. What is left is crash reporting, with keys, tokens and e-mail addresses filtered before sending.
What leaves your machine, and why
- Signing in and renewing your session: your e-mail and the access code, or what social login hands back.
- License verification, every few hours: the license token and the device identifier — not your project.
- The update check (operating system, architecture, channel and installed version) and the installer itself, when a new version exists.
- The marketplace catalogue, the docs, and the download of every pack you install — the install record carries the project path.
- The list of installed packs, when you ask the app to check them for updates.
- The conversation with the remote AI provider you chose, using your key: it carries whatever the agent read from your project to answer, plus your working directory path. With a local provider, none of it goes out.
- The contents of one file, if you ask the AI to settle an edit conflict during generation.
- Your API key, when you test the connection or ask a cloud provider for its model list — that round trip goes through our server.
- Checkout and subscription: the payment form is Stripe’s, runs inside the app and talks straight to Stripe, its own SDK telemetry included.
- The crash report, when the app breaks.
- Whatever you write in the support chat, the attachments you send, and the profile picture you choose.
- Your account notifications, the Help content and the release notes — plus, if you run an organisation or publish packs, whatever you do on those screens.
With a local AI provider and the marketplace left alone, the network traffic that remains is your account, the update check, and the crash report.
What people ask before downloading
Does Planuze replace my backend or generate one?
It generates one. What comes out is a project you open in your editor, run with the tooling you already have and ship to your own production — Planuze stays out of what you shipped.
Will it work with my stack?
That depends on the pack: column types, route types and the generator are declared by the installed pack, not by the core. The catalog of available packs lives inside the app, and another stack arrives as a new pack — yours or the community’s.
Does generation overwrite code I wrote by hand?
Not without you seeing it. Every write goes through a diff you approve file by file, and the generator runs in an isolated subprocess with no path to your disk outside that approval.
What happens to my model if I switch packs?
What you declared are JSON files inside the project itself, independent of the pack. Switching packs switches the generator and the vocabulary; what is declared stays in the repository.
Do I need to be online to work?
Not to model and generate. A connection is needed to verify your license, install a new pack and, if the AI provider is remote, for the agent — with a local provider the agent runs without leaving your machine.
Do I need an account?
Yes, and it is free: you sign in with a code sent to your e-mail, or through GitHub or Google, and there is no password to create. Picking a plan and setting up an AI provider are steps you can skip and settle later.
Do I have to pay to model and generate?
No: modeling and generating do not depend on a paid plan. What changes from one plan to another is the AI agent, session history, organization seats and private packs — the Pricing page reads the product catalog and shows what is published.
How does licensing work?
The license is verified by the app and applies per profile. Teams get an organization with seats, and packs private to the organization are visible only to people inside it.
Model one collection and watch the backend show up.
Local install and a free account. Whatever it generates lands on your disk.
Recommended for your system
Always the latest stable release.
Other update channels
The channels below get releases before stable. They update through the same mechanism as the app, but may carry bugs that are not fixed yet — use them on projects you can roll back.