SMF·QUICKBASE
Can a prompt replace Quickbase?
Databases — spreadsheet databases and operational data apps
Exhibit tracking slip
Verdict
Quickbase is bought by organisations that need one table read by three different roles who must not see the same columns — a salary field the manager sees and the coordinator does not, a supplier price visible to purchasing only. Enforcing that properly means permission checks at the field level in every query, every export and every API response, not a hidden column in the interface. Doing it correctly is a fortnight of careful work, and doing it incorrectly is a data leak.
Exhibit A — The prompt
Received on31.07.2026Build a records application whose defining feature is field-level permissions enforced at the data layer.
Schema: tables with fields typed as text, long text, number, currency, date, boolean, single select, multi select, attachment, user reference, and relation to another table. Relations expose a lookup field and a rollup (count, sum, min, max) on the parent side.
Roles and permissions, which is the point of this build. A role holds, per table, a record-level rule (all records, records where a user field equals the current user, records matching a filter expression) and, per field, one of: hidden, read, or write. Permissions are not a display concern:
- Every read goes through a query builder that selects only the fields the role may read. A hidden field must never appear in a response and then be filtered in the browser.
- Every write validates that the role may write each field being changed, rejecting the whole write if not, rather than silently dropping fields.
- The API returns exactly what the role may see, with the same rules as the interface.
- Export produces exactly the readable fields, with the role and the field list recorded in the export log.
- Search never matches on the content of a field the role cannot read, because a search result is an information leak even when the field is not displayed.
Write tests for each of those five paths specifically. Field permissions that are correct in the interface and leaky in the export or the API are the normal failure of this feature, and the tests are what stop it.
Views: grid, kanban grouped by a select field, and calendar on a date field. Views are per-role and can only reference fields that role may read.
Forms: a form per table exposing a chosen subset of writable fields, publishable to authenticated users or, optionally, publicly for a create-only role.
Audit: every create, update and delete recorded with the actor, the role, the fields changed, and their before and after values — with the audit log itself subject to field permissions, so a role that cannot read a field cannot read its history either.
Administration: role editor with a permission matrix, and a preview mode that renders any table exactly as a chosen role would see it. Nobody configures permissions correctly without being able to look through someone else's eyes.
Out of scope: SSO and directory provisioning, cross-application automation pipelines, a formula language beyond rollups and simple arithmetic, and any hosted multi-tenant deployment.
Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 the integration catalogue connecting to enterprise systems
- B.2 governance: SSO, provisioning, compliance certifications
- B.3 the scale and support an operations team depends on
- B.4 the pipeline automation between applications
Prior art
Exhibit C — Why people still pay: data model flexibility, collaboration, and integrations
Because when a business runs on the tool, the questions are about access control, audit and who is accountable when it breaks. That is procurement, not software, and it is what the price covers.
Questions
Can I export a Quickbase application?
Table data exports as CSV per table, so the records come across. The application definition — fields, relationships, roles, permission matrix and forms — has no portable export, so the schema and the permission model are rebuilt by hand, which is most of the work.
Why enforce permissions at the query layer rather than in the interface?
Because every application that filters in the interface eventually leaks through an export, an API response or a search result. Selecting only permitted fields at the query builder means there is one place to be correct, and it is the place the tests can reach.
What does it cost to run?
A VPS with PostgreSQL, ten to twenty dollars a month regardless of user count — against a per-seat price that scales with the team. For a team of ten this is a large saving on paper, and the saving is spent on being the person responsible for it.
What is the one thing that does not survive the rebuild?
Being answerable. Quickbase's customers need a vendor with certifications, a support contract and someone to call. A self-hosted permission model can be perfectly correct and still fail the only question that matters in an organisation: who is accountable if it is not.
Related tools
Receipt