Softr

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 a client portal that replaces Softr — and know what makes this ALMOST.

The feature that earns the price is **per-row permissions without code**: this client sees their own rows and nobody else's, configured rather than programmed. That is not hard to build — it is a predicate joined into every query — but it is easy to build wrongly, and building it wrongly means one customer seeing another's data. That is the whole verdict.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode, as the mirror of your source data
- No client-side framework
- Caddy in front

THE DATA MODEL
- sources: id, kind, config_encrypted, sync_interval_seconds, last_synced_at, last_error — a spreadsheet, a table product, a database, a CSV
- collections: id, source_id, name, slug, table_ref, sync_cursor
- fields: id, collection_id, key, label, kind, is_visible, is_filter, is_searchable, position
- Records in real SQL tables per collection, keyed on a stable identifier you nominate — never row position, or a re-sort renumbers everything on the site
- users: id, email, external_ref, role, attributes_json, is_active, last_login_at
- access_rules: id, collection_id, role, action, predicate_json — the heart of it: which rows, which fields, which actions
- pages: id, slug, kind, collection_id, config_json, required_role — list, detail, form, dashboard
- audit: id, actor_id, action, collection, record_id, at — append-only

THE PERMISSION RULE, WHICH IS THE PRODUCT
- A predicate over the row and the signed-in user: `row.client_email = user.email`, or `row.account_id in user.account_ids`
- **Compiled into the WHERE clause of every query.** Never fetch and filter afterwards — a filtered result set still travelled, and one mistake in a template exposes it
- A forbidden field is absent from the response, not hidden in the page
- Default deny: a collection is invisible until a rule grants it
- A rule tester: pick a user, pick a record, and see whether access is granted and which rule decided. Without it, permission questions become guesswork
- A page listing every rule in plain language, generated from the table. That page is what you show somebody who asks whether their data is safe
- Test the negative case explicitly: sign in as one client and try to reach another's record by identifier in the URL. That test is the acceptance criterion for the whole build

SYNCING FROM THE SOURCE
- Mirror locally and serve from the mirror. Serving directly from a spreadsheet API is slow, rate-limited, and goes down when the source does
- Incremental with a cursor where the source supports it, full otherwise, on a schedule and on demand
- A record that disappears is marked missing rather than deleted, so a page returns a clear gone state rather than a broken link
- Writes from a form go back to the source, idempotently, with the local mirror updated on success. Never write to the mirror alone, or the two will drift

THE PAGES
- List with search, filters and pagination, respecting the row rules
- Detail, at a permanent URL, respecting them again
- Form, writing back to the source with server-side validation
- A simple dashboard of counts and totals, computed at query time from what this user may see
- Everything works at 320px and on a poor connection

AUTHENTICATION
- Magic links, because a client portal with a password is a portal with a password reset queue
- Sessions as long random tokens stored hashed, revocable, with a device list
- Users provisioned from the source data itself — the client list is already a table — or invited by email
- Rate limits on every authentication route

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, ENCRYPTION_KEY, HASH_SALT, SMTP_URL, source credentials
- Migrations on boot, each once; nightly backup off the machine
- Health endpoint reporting the age of the last successful sync — a stale portal that looks fine is the quiet failure here

WHAT MATTERS MOST
The predicate in the query, and the negative test. Build access rules before any page exists, then spend an afternoon trying to see somebody else's row. Everything else here is a list view.