Glide

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 mobile app I actually need instead of Glide — and know why this is ALMOST.

What you are paying for is **a phone app produced from a table with no build pipeline, no store account and no release process**. That last part is the real barrier: publishing a native application means developer accounts, review queues and a release every time you change a label. The honest replacement is an installable web application, which avoids all of it — and gives up a few things. Read the next section before deciding.

STACK
- Astro or Fastify with server-rendered HTML, delivered as an installable PWA
- SQLite through better-sqlite3, WAL mode, as the mirror of your source data
- A service worker for offline, and IndexedDB for the queue
- Caddy in front

WHAT A PWA DOES AND DOES NOT GIVE YOU
- Yes: installable to the home screen, full screen, offline, camera, geolocation, and a share target. That covers the great majority of internal and small-business applications
- Not reliably: push notifications on every platform, background sync, and deep hardware access. Check what your users' devices actually support before promising anything
- And no store listing, which for an internal tool is a benefit rather than a loss
- Write this list in the README, honestly, because it is the whole decision

THE DATA
- The source can be a spreadsheet, a table product, a database or a CSV. One adapter interface, several implementations
- Mirror it locally and serve from the mirror. Serving directly from a spreadsheet API is slow, rate-limited, and goes down when the source does
- records in real SQL tables per collection, keyed on a stable identifier you nominate — never row position, or a re-sort renumbers everything
- Sync incrementally with a cursor, on a schedule and on demand, with a webhook for the source to trigger one
- A record that disappears is marked missing rather than deleted, and its screen says so rather than breaking

THE SCREENS
- Four kinds cover almost everything: a list with search and filters, a detail, a form, and an action
- Defined in code as files, not built by dragging. That is faster to write, easier to review, and produces something that fits your data
- Navigation as a bottom bar with three or four items, because that is how phones are held
- Everything works at 320px, with real touch targets and no hover-only interaction

OFFLINE AND WRITES
- The service worker caches the shell and the last-fetched data, so opening it in a basement shows something
- Writes go into a queue in IndexedDB and are sent when there is a connection, each with a client-generated identifier so a retry never creates two records
- Conflicts: a write against a stale version is rejected and shown, never silently overwritten
- The user must be able to see what is pending. A queue nobody can inspect is a queue nobody trusts

THE REST
- Authentication by magic link, with a long session, because typing a password on a phone is a barrier
- Roles checked on the server for every screen and every write, default deny
- Images resized on upload, EXIF stripped, stored by hash
- An install prompt shown at the right moment, with instructions for the platform that hides it

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

WHAT MATTERS MOST
The offline write queue and stable identifiers. Get writes queued and visible, and never let a re-sorted source renumber your records; those two are what separate a usable field application from a website with an icon.