Why FRGMNT has no backend

Updated 2026-08-04

Most apps in this category are a web service with a mobile client. FRGMNT is the opposite: the app is the whole thing.

How it works

  your iPhone
       │
       │  read-only keys (iOS Keychain)
       │
       ├──▶  api.stripe.com
       ├──▶  api.lemonsqueezy.com
       ├──▶  api.gumroad.com
       └──▶  api.paypal.com
                │
                ▼
        aggregate() on device
                │
                ▼
        True MRR / today's cash

There is no step where data passes through a server we control, because we don't run one for this.

The revenue adapters are framework-free TypeScript — no React Native imports — which is why the identical code runs in the app, the CLI and the MCP server. See the developer page.

What it buys

Nothing to breach. No database of founders' API keys exists.

Nothing to subpoena. We cannot produce your revenue data because we don't have it.

No account. No email, no password, no profile. Nothing to leak, nothing to delete, no sign-up friction.

No trust required. You don't have to believe a privacy policy. The architecture makes the claim structurally rather than contractually — which is a much stronger form of assurance.

What it costs

Being straight about the trade-offs, because they're real:

No background polling. A hosted tool's servers poll your data continuously. FRGMNT fetches when the app runs. Sale alerts use a separate mechanism.

No web dashboard. There's no server to render one.

No cross-device sync. Keys live on one device. Setting up a second means pasting them again.

Manual credentials. No "connect with OAuth" flow — those require a server to hold the token. You generate a restricted key and paste it.

Limited historical data. No server means no long-term history warehouse. The app shows current state plus a local cache, not two years of cohorts.

If any of those matter more to you than the privacy properties, a hosted tool is genuinely the better choice. ChartMogul is free under $10k MRR.

The one piece of infrastructure

Push notifications are the exception, and worth being precise about.

For a sale alert to arrive while the app is closed, something must be running. FRGMNT uses a stateless relay: provider webhooks hit a small Cloudflare Worker, which forwards a notification to Apple's push service.

What that relay does not do:

store the event
hold your API keys
keep a database
retain anything after forwarding

It's a pipe, not a store. Push is optional — decline it and the relay is never involved.

Offline behaviour

The last successful response is cached locally so the app shows your most recent figures without a connection, clearly marked as cached rather than live. That cache is on your device.

Why this way

Because the alternative means a database containing thousands of founders' live payment credentials and full revenue histories. That's a target we'd rather not create, and a responsibility we'd rather not hold.

The trade-offs above are the price. For the specific job of "what am I making right now, across everything", it's a good trade.

Frequently asked

How does an app work without a backend?

It calls third-party APIs directly from the device. FRGMNT holds read-only keys in the iOS Keychain and requests data from Stripe, Lemon Squeezy, Gumroad and PayPal from the phone itself, rendering results locally.

How do push notifications work without a server?

A stateless relay forwards provider webhooks to Apple's push service. It passes the event through without storing it and holds no revenue data or credentials.

What are the downsides of no backend?

No background polling while the app is closed, no web dashboard, no cross-device sync, and you manage credentials yourself rather than connecting via OAuth.