The backend that isn’t there

§ There is no app server

NextHaul has no backend of its own. The database is the backend. The few things a phone can’t be trusted to do safely (consume a one-time invite, decide who gets a notification, delete rows) run as guarded functions inside Postgres, and the database itself makes the outbound calls to send a push. That collapses a whole tier of custom server code into the database.

§ Two apps, one database

NextHaul shares a single database with Cadora. Instead of building a bridge between two systems, both repos keep byte-identical copies of the schema migrations and generate typed models from them. The database is treated as a contract, so a renamed column becomes a compile error instead of a runtime surprise.

§ Invites and identity that resist abuse

Single-use invite codes are consumed inside a guarded function that returns the same “invalid or expired” for every dead code, so there’s no way to probe which codes exist, and there’s a per-user attempt throttle on top. A durable device credential means reinstalling the app recovers your household instead of orphaning it, so “create, drop, create” becomes “create once, then restore.”

§ Push notifications, done carefully

The push sender is full of small, correct choices. Untrusted device tokens are tracked in a structure that can’t be tripped up by a malicious key name, a muted member’s tokens are never even fetched, rapid-fire notifications collapse into one, and if the app can’t tell who triggered an update it stays silent rather than risk mis-notifying.