Supabase public evaluation flow — Hovvi

What happened

Lead with the database engine promise, let visitors map the integrated modules, prove one product concretely, then compare usage quotas before the account gate. Let a founder move from a platform promise through an integrated module map, one product's concrete proof and published usage quotas to an explicit account boundary.

Evidence

Observed facts

• The English homepage leads with Build in a weekend, scale to millions and pairs a green Start your project action with a Request a demo path.
• The Product menu presents Database, Auth, Storage, Edge Functions and Realtime as integrated modules, adds Vector, Cron and Queues extensions and links comparisons against Firebase, Heroku Postgres and Auth0.
• The Database page opens on Postgres without the hassle and proves it with spreadsheet-style table editing, table creation and row-level security policy examples.
• The pricing page titled Predictable pricing, designed to scale separates a Free plan of 50,000 monthly active users, 500 MB database and 1 GB file storage from a Pro plan from $25 per month with published per-unit rates.
• The sign-up boundary offers Continue with GitHub, Continue with ChatGPT and email account creation before any project exists.

Editorial inference

• Staging the promise, module map, product proof and quotas before the gate reduces evaluation ambiguity; Hovvi should keep case evidence browsable before any account exists.

Product flow

1. Platform promise
2. Integrated module menu
3. Database product proof
4. Plan comparison
5. Account boundary

Founder takeaway

Prove the engine and its modules in public, publish the quotas, and ask for identity only when a project begins.

Use when

• A platform bundles several infrastructure modules under one brand
• Prospects compare usage quotas before creating an account

Avoid when

• The product portfolio is too small to need a module map
• Public pages cannot represent the post-sign-up product

Next implementation step

Design a public evaluation journey that moves from a platform promise to an integrated module map, one product's proof, usage quotas and an explicit account boundary.

Acceptance criteria

• Every evaluation stage resolves to a rights-qualified observed screen
• A visitor can move from the platform promise to the Database proof and pricing without creating an account
• Usage quotas and marginal rates are visible before the account boundary
• The account boundary names its identity methods before any data entry
• Authenticated continuation is explicitly excluded until observed

Related cases

• Evaluate, then activate: Supabase project activation flow — Hovvi

  The public evaluation path explains the Postgres promise, integrated modules and usage quotas before the activation flow shows the account gate, inline validation and recovery at first commitment.

• Same evaluation arc, different proof: Cloudflare Workers public product evaluation flow — Hovvi

  Both brands move anonymous visitors from a platform promise through product discovery and plan comparison to an explicit account boundary; Supabase proves an integrated Postgres backend while Cloudflare proves a runnable edge sandbox.

Version history

Current snapshot: snap_supabase_public_evaluation_2026_08_25 — Added the first complete Supabase flow: anonymous evaluation from the Postgres promise through the integrated module map, one product's proof, published usage quotas and the account boundary.

Use with an Agent

Example read-only MCP query: