Budibase

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the internal app I actually need instead of a hosted Budibase: forms and screens over my own data, with automations on row changes and roles that are enforced.

Read this first: the product you are replacing is open source and self-hosting it is a real answer — most people who use it do. What the paid tier sells is role-based access, single sign-on and support. Build this instead when the app is a handful of screens with a few automations, which is what most of them are.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3 for the app's own data, or a connection to an existing database
- No client-side framework
- Caddy in front

THE DATA MODEL
- users, roles, permissions, sessions, audit_log — as in any internal tool, with permissions checked on the server and the default set to deny
- screens defined in code: a list, a detail, a form, an action. Four kinds cover almost everything, and each is a file rather than a row in a builder's schema
- automations: id, name, trigger_kind, trigger_config_json, steps_json, is_active
- automation_runs: id, automation_id, trigger_payload_json, status, started_at, finished_at, error
- automation_step_runs: id, run_id, step_index, input_json, output_json, status, error, ms
- queue: id, run_id, run_at, attempts, locked_by, locked_at

THE DATA UNDER IT
- If there is already a database, connect to it read-mostly and write through named, parameterised statements
- If there is not, this tool's SQLite is the database, with a proper schema and migrations — a built-in database is the reason these products get adopted by teams who have none, and a real table beats a generic store every time
- Every table gets created_at, updated_at, and a revisions log for the fields that matter

SCREENS
- List: filters, sort, pagination, a defined column set, and a row limit that is never unbounded
- Detail: fields, related records, and the actions this role may take here
- Form: typed fields, server-side validation, a honeypot if it is public, and a clear error path that keeps what was typed
- Action: a named mutation with a confirmation, a permission, and an audit entry. Never a free-form query box
- Everything works on a phone, because half of internal-tool use is somebody away from a desk

AUTOMATIONS, WHICH IS THE HALF PEOPLE UNDERESTIMATE
- Triggers: a row created, updated or deleted; a schedule with a time zone; a signed webhook; a button on a screen
- A row-updated trigger fires from the same transaction that made the change, recorded to a queue table — not from polling, and not from a trigger that can fire twice
- Steps: send an email, call an HTTP endpoint, write a row, branch on a condition, loop over a list, run a small sandboxed script, delay
- Every step's input and output stored, so 'why did this customer get that email' is answerable a month later
- Retries with backoff and jitter; a permanent failure lands in a dead-letter list with a one-button replay
- Deduplication so a redelivered webhook runs once

EMAIL AND NOTIFICATIONS
- Templates in Markdown with a preview and a test send
- Every send recorded with its recipient, template and payload
- A per-recipient daily cap for automated mail, so a loop in an automation cannot mail somebody four hundred times. This costs an afternoon and saves a very bad day

PERMISSIONS AND AUDIT
- Roles, server-side checks, row-level scope where the data needs it
- Append-only audit log of every mutation, export and permission change, with before and after values
- Single sign-on through OIDC, with magic links as the fallback

OPERATIONS
- .env: DATABASE_PATH, TARGET_DATABASE_URL, BASE_URL, SESSION_SECRET, SMTP_URL, OIDC_*, HASH_SALT
- Migrations on boot, each once
- Behind whatever the company already uses for staff access; public exposure is a deliberate decision
- Nightly backup off the machine, restore script
- Health endpoint reporting queue depth and the oldest unlocked job

WHAT MATTERS MOST
The automation queue and the per-recipient mail cap. Build those before any screen, then kill the process mid-run and confirm nothing is lost and nothing repeats. The screens are an afternoon each; an automation that fires twice on every row update is the failure that makes the whole thing untrustworthy.

Give me the repository, migrations, .env.example, an example app of four screens and two automations, and a README with deploy steps behind Caddy.