Ship the iOS/Android app — the backend is done.
Apple, Google and passwordless sign-in, a bearer-token JSON API, profiles and per-user data — the whole backend your app needs, on plain PHP and SQLite. No Firebase bill, no SDK to babysit.
This download ships two real native apps (SwiftUI + Liquid Glass on iOS, Jetpack Compose + Material 3 on Android) already wired to one PHP backend. It verifies Apple/Google/passwordless sign-in, hands the app a bearer token, and serves a clean JSON API over per-user data. Set one URL and run — no Firebase bill, no SDK to babysit.
The backend proves a login really came from Apple or Google before trusting it, so a forged sign-in can't impersonate a user. The app sends the provider proof token (id_token); the backend verifies its signature against Apple/Google's public keys (JWKS) before trusting a single claim, then finds-or-creates the user through the same identity-linking path the web login uses. No client claim is taken on faith.
app_request_code emails a 6-digit code; app_verify_code checks it and returns a token. It reuses the exact login-code mechanism the website uses, so there is one auth pipeline to reason about and no passwords anywhere in the database.
Sign-in mints a long random at_ token returned once. Only a peppered HMAC-SHA256 hash and the device label hit the database; last_used_at is stamped per call, and any device can be revoked. A leaked DB hands an attacker nothing usable.
app_me, app_profile_update, app_logout and a full app_items CRUD ship as working, per-user-scoped endpoints with consistent JSON envelopes, status codes and validation. Clone app_items into your own models and keep the shape.
Each app token is throttled by a fixed-window limiter in SQLite — 300 requests per 60s out of the box, one env var to change. Over the line returns 429 with a Retry-After header. No Redis, no sidecar.
The member app is a backend console: app users with their auth provider and last-seen, the live app data, which sign-in methods are enabled, issue/revoke app tokens, and a copy-paste cURL + Swift quickstart. Subscriptions are wired for in-app plans.
A SwiftUI + Liquid Glass iOS app and a Jetpack Compose + Material 3 Android app ship in clients/, already wired to this exact API and to RevenueCat — social + email sign-in, a dashboard reading app_me, profile edit, a per-user items CRUD, and an in-app paywall. Set your backend URL in one config file, open in Xcode / Android Studio, and run. Auth just works.
Your app sends the provider id_token; the backend verifies its signature, finds-or-creates the user, and returns a bearer app token the app stores. Every call after that is one header.
# 1. Sign in: the app posts the Apple/Google id_token. curl -X POST https://api.yourapp.com/api.php?action=app_auth_apple \ -d '{"id_token":"eyJ...","nonce":"a1f3","device":"iPhone 15"}' { "ok": true, "token": "at_9f2a…", "user": { "id": 51, "email": "ada@app.dev" } } # 2. Every call after: one Authorization header. curl https://api.yourapp.com/api.php?action=app_items_list \ -H "Authorization: Bearer at_9f2a…" { "ok": true, "items": [ { "id": 12, "title": "Hello" } ] }
Every figure here is how the backend actually behaves the moment you deploy it — not a sales chart.
You're in one now. Hop straight to any other site type — same tab, still a demo: no card needed, no payment is real, and nothing you do is saved.
Each site-type demo is one of the seven ready-to-run profiles in the download — copy the folder, add your keys, ship.
Most SaaS dies of complexity, not competition.
| daily_hits | 100,000+ |
| cost / 10k logins | $1 |
| whole_stack / month | < $10 |
| reads_block_writes | never · WAL mode |
Every install ships with this. Search users, replay webhooks, inspect billing and revoke keys — server-rendered, access-gated, no second app.
| User | Plan | Status | Joined |
|---|---|---|---|
| ada@example.com | Pro | active | 2d ago |
| grace@example.com | Scale | active | 5d ago |
| linus@example.com | Starter | past due | 3w ago |
| margaret@example.com | Pro | active | 1mo ago |
| blocked@example.com | Free | blocked | 1mo ago |
invoice.paidevt_1Q8x…a3customer.subscription.updatedevt_1Q8w…f1checkout.session.completedevt_1Q8w…7cinvoice.payment_failedevt_1Q8v…02charge.refundedevt_1Q8u…9dcurl -H "Authorization: Bearer ss_live_••••" \ https://app.yoursaas.com/api.php?resource=notes { "ok": true, "data": [ "note_18f2", "note_18f9" ], "rate_limit": "58/60", "credits_left": 1840 }
copy a template folder
composer install · Stripe + SES
rebrand · plans · run doctor
NGINX + PHP-FPM · take cards
unzip → live on a VPS — one afternoon.
Define plans in app/subscriptions.php, attach Stripe price IDs, and the checkout flow stays generic across every project.
Default access for new users and trial accounts.
For a small paid SaaS tier.
For heavier usage and premium features.
For power users and high-credit products.
With Apple, Google or a passwordless email code — provider tokens are verified against the real Apple/Google keys before a session is minted, and the app keeps a long-lived bearer token. No passwords anywhere.
A clean bearer-token JSON API: the signed-in user's profile plus a per-user data resource you clone per model. Rate-limited, PII-safe, no cookies or CSRF to fight from native code.
Yes — native in-app subscriptions via RevenueCat land on the same access levels and credits as Stripe, from one webhook. Gate features server-side with a single check.
Yes — parameterised SQL throughout, signed Stripe webhooks, CSRF, rate limiting and session hardening, all security-reviewed. Real plumbing, not a toy.
One small VPS runs the whole stack for a few dollars a month, and passwordless login emails on Amazon SES are about $1 per 10,000 sign-ins. Prefer Apple or Google sign-in? Both are built in with no per-login cost — Google's is free, and Apple's only needs an Apple Developer account ($99/yr) you likely already have to ship an app — so you can skip login emails entirely. No per-seat platform bills.
This is a live, fully interactive demo — explore every screen. Nothing you do is saved and no payments are real.