Konsey — Multi-Model LLM Council

What happened (real run, 18 Oct 2026, total 6 min 38 s)

Peer ranking (mean rank, lower is better; authors revealed after judging):

(Self-preference check: Argon and Sol each ranked their own answer first; Opus ranked its own answer third.)

Chair's final answer (final.md, unedited)

Decision: build the MVP backend on Supabase, with server-owned business rules

Use Supabase for Auth, Postgres, Storage, Cron and a few Edge Functions. Don't write a custom Go API for the MVP. The main risk at this stage is whether strangers will write slow letters and come back to reply. A custom Go API doesn't help you find that out. Auth flows, token refresh, deploys and an admin UI take weeks that two founders should spend on the product.

There is one condition. The mobile client must not be trusted with anything that matters. It never sets delivery times, sender identity or moderation status, and it never sees coordinates. Sending, blocking and reporting go through narrow server-side functions. A thick client writing straight to tables is the most likely way this MVP fails.

The one exception: choose Go if a founder already has a production-ready Go setup (auth integration, migrations, deploys, background jobs, monitoring) and is clearly faster in it. Compare against what you actually have today, not an ideal. Even then, use managed auth (Supabase Auth or similar) and managed Postgres. Don't write auth yourselves.

Why

Most of the feature list is commodity work. Auth, profiles, storage and a table of reports are what Supabase already provides. The only new mechanic is distance-delayed delivery, and it fits in Postgres.

The language matters less than the architecture. Most of the advice below applies equally to Go. Go is not safer by default: a missing authorization check in a Go handler leaks data just as a wrong RLS policy does. RLS policies are security code, and they need tests.

Lock-in is moderate, not zero. The data is plain Postgres and exports easily. Auth, policies, functions and client coupling still need migration work. That is acceptable because the exit path is gradual (see "When to revisit").

How the core mechanic should work

Delivery is a permission that opens at a time, not a job. The send_letter function computes deliver_at on the server. It uses a snapshot of both users' coarse locations and a versioned delay formula, and stores the result. The recipient can read the body only when deliver_at <= now() and the letter is still eligible. No scheduler is needed for visibility, and nobody needs to flip a status. Never download the body early and hide it behind a countdown on the phone.
2. If the app shows "a letter is in transit", keep the envelope and the body apart. RLS works on whole rows, not columns. If the recipient can select the row to draw the in-transit UI, they can also query the body with their own token. Use either a separate letter_contents table gated on deliver_at, or a view or function that returns NULL for the body until delivery.
3.

Notification is a separate job from visibility. Cron scans due, unnotified letters in small batches using an index. It claims each batch atomically (FOR UPDATE SKIP LOCKED plus a processing status and a locked_until lease), or you use

Supabase Queues instead of building that yourself. Before sending, it rechecks eligibility (blocks, suspensions, deleted accounts), then sends through FCM/APNs and records the result.

• Delivery is at-least-once. A crash after the provider accepts a push but before you record it causes a duplicate on retry. Use stable notification IDs or collapse keys so devices drop duplicates.
• A failed push must never keep a letter out of the inbox.
• Never leave a function sleeping until delivery time. Edge Functions have execution limits.

Keep location private. Store coordinates or a geohash in a private table that authenticated users cannot read through the API. Show only city-level labels. Round delays into bands, because exact delays let someone work out where a person lives. A user who moves does not change letters already in transit.
5.

Be careful with SECURITY DEFINER. Use it only where a function must bypass RLS. Pin search_path, restrict who can execute it, and check auth.uid() and ownership explicitly inside it. Otherwise use invoker security.

Now, later, never

Now (before launch)

• Supabase

Pro plan, not Free (Free projects pause when inactive and lack proper backups). Choose the

region deliberately, because it is set when the project is created and location data is personal data under GDPR.

• Turn off direct client writes to letters. Write send_letter, block_user and report_letter as server functions. send_letter checks blocks, enforces quotas and eligibility, and accepts an

idempotency key so mobile retries don't create duplicate letters. Profile edits can use direct RLS limited to safe columns.

• Write

pgTAP policy tests (supabase test db). At minimum: an unrelated user can't read letters, the recipient can't read before deliver_at, the client can't set deliver_at or the sender, and a blocked user can't send.

• Gate

Storage too. If letters can carry photos, stamps or audio, the bucket policies or signed-URL generation must also enforce deliver_at. Otherwise attachments leak early.

• Abuse basics: CAPTCHA on signup (hCaptcha or Turnstile), rate limits, and block and report flows inside the app. Write down what happens to in-transit letters when someone blocks the sender, gets suspended or deletes their account. Account deletion is required in the app and must cascade to those letters.
• Moderation workflow: a private review queue, ban/block actions, and limited access to evidence. Supabase Studio is fine for the two founders at first, but it has full access to everything. Plan a small internal page that uses the service role key on the server side only.

Age policy and child-safety measures. An app where strangers write to strangers attracts minors. Settle age rating, age gating and safeguards before launch. This may matter more than the backend choice.

• Development: use the Supabase CLI's local stack and a separate staging project, and keep every migration in version control. Add

internal test accounts with near-instant delivery so a QA cycle doesn't take days.

• Monitoring: alert on

the age of the oldest overdue unnotified letter. That catches cron stopping silently, which retry logic doesn't. Check cron.job_run_details.

• Push UX: ask for notification permission right after the first letter is sent. Clean up dead device tokens. Consider holding the push until the recipient's local morning while the letter itself stays visible.
• Product metrics: first letter sent, arrival, first reply, and reciprocal exchanges, measured over complete delivery cycles.

Later (when there is evidence)

• Automated moderation of letter content before it enters the queue (keyword rules, a classifier, or a moderation API).
• Matching logic more complex than a single SQL query.
• A Go worker or a few Go endpoints running against the

same Postgres and verifying Supabase JWTs. Move delivery/notification and moderation first.

Never

• Writing auth yourselves, in Go or anything else.
• Letting the client compute distance or deliver_at.
• Exposing coordinates on a profile other users can query.
• Shipping the service role key in the app.
• A rewrite triggered by funding, headcount or a round user count.

When to revisit

Do the first review after the first cohort has completed several full exchange cycles. After that, revisit when

any one of these measured problems persists:

Notifications are unreliable: a growing backlog of overdue notifications, Edge Function timeouts, or a recurring retry/duplicate problem.
2.

Logic is hard to change safely: branching rules spread across PL/pgSQL, Edge Functions and the client, policies nobody can confidently review, or bugs traced to that split.
3.

The workload doesn't fit: long jobs, fan-out, moderation pipelines or retries with backoff that need workarounds on the platform.
4.

Cost: the total bill, including the founders' maintenance hours, clearly exceeds the alternative. Compare it with a VPS plus the backups, auth and on-call work you'd take on, not with the bare VPS price.
5. A compliance or contract requirement that the hosting can't meet.

The numeric thresholds the members proposed (deliveries per minute, RPC counts, monthly spend) are judgment calls, not benchmarks. Track backlog age, retry failures, database latency and hours spent on maintenance, and decide from those numbers. The likely next step is adding Go alongside Supabase and moving one component at a time, keeping Supabase Auth possibly for good. It is not a rewrite.

Open risks to verify

Apple guideline 4.8: the current wording asks for an "equivalent privacy-focused login option", with exceptions. It may not strictly require Sign in with Apple. Check before choosing auth providers.

Store UGC rules: Apple 1.2 says "timely" action on reports, and Google requires ongoing moderation. A blanket 24-hour deadline is not clearly stated. Confirm the current terms.

• Age and online-safety law for your target markets (COPPA, the UK Online Safety Act, the EU DSA). Get a review.

Supabase plan details: Free-tier pausing and backups, Pro pricing, Edge Function limits, and the delivery guarantees of Supabase Queues.

Expo integration: if you use Expo, the usual route is @supabase/supabase-js with Expo auth helpers. Confirm any package name before relying on it.

• Backup restore: run a restore once and set recovery objectives. A backup you have never restored is unverified.

Decisions left to you

Do you have a production-ready Go foundation today? If yes, and it is clearly faster for you, Go with managed auth is reasonable. If no, use Supabase.
2. Do recipients see letters while they are in transit? If yes, the envelope/body split is required.
3.

The delay formula and location granularity: city or region, the delay bands, and whether users choose their location or it is detected.
4. Age policy and launch markets. This sets your legal obligations and the moderation workload.
5.

The privacy promise for letter contents: who on the team can read letters, how long they are kept, and whether the push payload includes any text.
6. Moderation staffing: who handles reports, and how quickly, from launch day.
7. Login methods: email only, or also Apple and Google, subject to the 4.8 check above.