Scalability & Performance

Every coach turn is amplifying database load by a factor of ~17 and token cost by sending the full user-state snapshot to the LLM. With 100 concurrent users each sending one message per minute, that is ~1,700 Postgres queries per minute on top of the embedding overhead. Supabase pooler default of 60-90 connections will saturate well before the user-load justifies it. There is no caching of the assembled context: two messages 5 seconds apart by the same user re-run all 17 queries from scratch.

At 100 daily active users sending 10 messages/day, the chat path alone executes ~17,000 Postgres queries per day from the coach endpoint. At 1,000 DAU this is 170k queries/day. AI-gateway cost: an 8-12 KB system prompt at ~3000 input tokens x 10 turns/day x 1000 users = 30M input tokens/day. At openai/gpt-5 indicative pricing (~$5/1M input tokens) that is ~$150/day input cost just for the coach endpoint context.

Every time a user sends a chat message to your coach, your server runs around 17 database queries and packs the user entire week of biometrics, full profile, all today meals and workouts into the prompt sent to OpenAI. None of this is cached, so two messages five seconds apart re-do all the work.

1. Introduce a per-user context cache keyed by (userId, dayKey) with a 60-90 second TTL via Cloudflare Workers KV or an in-Worker Map.
2. Split the context blocks by volatility: profile (5 min cache), biometrics-7d (5 min), today meals/lifestyle (15 sec, invalidate on log events).
3. Reduce the prompt: summarise meal/lifestyle rows numerically rather than JSON-stringifying.
4. Use Postgres views or RPC functions to fold 11 queries into 2-3.
5. Add a token-count log per turn and alert when system_prompt_tokens > 4000.

L — 1–2 weeks

• https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pooler
• https://platform.openai.com/docs/guides/prompt-caching

Every text-coach turn now incurs TWO openai/gpt-5 calls: the streaming response (max_completion_tokens: 1600) plus the fact-extraction. For voice-coach turns the extractor is NOT called, so cost asymmetry between text and voice is unexpected. Fact extraction provides marginal value (most turns produce 0 new facts) but doubles per-turn AI cost. It also runs synchronously in the request handler. Combined with SCA-001, a single user message triggers ~17 Postgres queries + 2 paid GPT-5 calls.

At 1000 DAU x 10 messages/day, ~10,000 extra openai/gpt-5 calls per day - at indicative pricing $5/1M input + $15/1M output, ~1000 input + 200 output tokens per call ~$10-15/day of pure overhead. A power user firing 50 messages in one session hits the gateway 100 times in minutes.

Every chat message a user sends actually triggers two AI calls: the visible reply, and a hidden background call that tries to extract long-term facts. You pay for the hidden call on every turn even when it returns nothing.

1. Throttle fact extraction to every Nth turn (e.g. every 5th user message).
2. Extend the personal-disclosure keyword pre-filter on line 454.
3. Move fact extraction off the request hot path via Cloudflare Queue or a scheduled cron.
4. Use a cheaper model (gpt-5-mini, gemini-flash) for this classification task.
5. Cap with AbortSignal so a slow gateway cannot block the request handler.

S — under ½ day

• https://developers.cloudflare.com/queues/
• https://platform.openai.com/docs/models

Every visitor downloads JSON for all six languages on first page load even though they will only ever read one. After gzip the payload is roughly 200-280 KB of redundant translation text - large for a mobile-first PWA where TTI is heavily affected by JS size. The i18n module is imported eagerly at the root (__root.tsx:13), so the bundler cannot split it out of the critical-path chunk. For the Cloudflare Worker SSR pass all six locale JSONs are bundled into the Worker code itself, contributing to the 10 MB compressed Worker limit and to cold-start parse time.

Slower first-contentful-paint on every visitor - especially mobile on cellular. ~200 KB of avoidable JS adds ~300-500 ms to interactive on a mid-tier Android. Core Web Vitals (LCP/INP) are affected. Cloudflare Worker cold-start: each cold isolate parses the locale bundles, adding ~50-100 ms to that subset of requests.

Your app supports six languages but every visitor downloads all six translation files on first visit - about 200 KB of extra data. The fix is to fetch just the user language on demand.

1. Adopt i18next-resources-to-backend or i18next-http-backend and split locales into one chunk per language.
2. Keep en.json in the critical chunk; lazy-import the others via dynamic import of ./locales/de.json.
3. Consider namespace splitting (onboarding, settings, errors only loaded on those routes).
4. Add a bundle-size budget to CI.
5. Verify with vite-bundle-analyzer how much of the current bundle is locale JSON.

M — 1–3 days

• https://www.i18next.com/how-to/backend-fallback
• https://github.com/i18next/i18next-resources-to-backend
• https://web.dev/articles/optimize-lcp

On day 30 of usage a daily user has ~30 conversations x 20-50 messages each = 600-1500 message rows. By day 180 that is 3,600-9,000 rows. The query loads them all into memory and renders via react-markdown. Three failure modes: bandwidth (5-15 MB on every chat-sheet open after months); render time (react-markdown invoked per message causes main-thread stalls); database (user_id with no LIMIT means the planner falls back to scan-and-filter as the user table grows). No index supports coach_conversations(user_id, updated_at) for the conversations list query.

UX degrades silently the longer the user uses the product. A heavy user 6 months in sees a 3-5 second freeze when opening the chat sheet. Cost angle: every chat-sheet open re-downloads the entire history (no client cache) - Supabase egress fees scale linearly. Database angle: with 10k users averaging 1000 messages each, this query pattern over a 10M-row table becomes the dominant Postgres workload.

When a user opens the chat with their coach, your app downloads every message they have ever sent or received. After a few months of daily use that is thousands of messages - megabytes of data on every open. The fix is to load only the most recent 50-100 messages and paginate older ones.

1. Add LIMIT 100 (or.
2. and ORDER BY created_at DESC to messages query; reverse client-side.
3. For conversations list add LIMIT 20 ORDER BY updated_at DESC.
4. Infinite-scroll pagination using .lt(created_at, oldestLoadedTimestamp).
5. Add covering index coach_conversations(user_id, updated_at DESC).
6. Archive messages older than 90 days to a coach_messages_archive table.
7. Cache fetched history in tanstack-query with a 60-second staleTime.
8. Log response size to alert on > 1 MB per open.

M — 1–3 days

• https://supabase.com/docs/guides/database/postgres/indexes
• https://tanstack.com/query/latest/docs/framework/react/guides/infinite-queries

When the AI gateway has a transient slow-down, every in-flight coach request hangs until the Worker kills it at 30 s. The user sees a spinning indicator then a hard error. The retry logic in callGatewayWithRetry retries on transient 5xx - but if the first call is stuck (no response), it never enters the retry branch. Combined with the inFlightTurns dedup (45 sec window), a hung request also blocks the user from retrying the same message for 45 seconds.

During an AI gateway incident every coach request is degraded - users see a long delay then a hard error, and may abandon. Worker bill is also affected: stalled requests consume the full 30s CPU/wall budget. At the upper bound of 100 concurrent stuck requests, queueing backlog can measurably degrade p99 for the whole app, not just chat.

If the AI service is slow your server has no time limit on waiting for it. Each chat request can hang for 30 seconds before failing, tying up resources other users need. The fix is a 15-20 second timeout and fail-fast behaviour.

1. Wrap every fetch to the AI gateway in an AbortController with a 20-second timeout.
2. Centralize in a helper aiGatewayFetch(url, opts, { timeoutMs }).
3. On AbortError treat as transient 5xx and let retry path run.
4. Explicit 15-second timeout to the SSE first-byte.
5. Log timeout vs error vs success per call.
6. Add a Cloudflare limits.cpu_ms guard in wrangler.jsonc.

S — under ½ day

• https://developer.mozilla.org/en-US/docs/Web/API/AbortController
• https://developers.cloudflare.com/workers/platform/limits/

These cron handlers will run today (small base) but will silently fail to complete as the userbase grows past ~30-50 active users. The Worker dies at 30 seconds; pg_cron times out at 60 seconds. Loop interrupted mid-iteration with no resume marker - most users miss their weekly report or plateau check. No idempotency token, no resume cursor. Combined with unauthenticated cron endpoints (SEC-002, SEC-003), an attacker can hit them repeatedly to amplify cost.

Silent feature degradation as you grow: at 30 users today everything works; at 100 users cron starts cutting off mid-batch; at 500 users it never finishes. End-user-visible symptom is mysterious: power users report missing Sunday reports. AI cost: each timed-out cron still consumed credits for every user processed before the cut.

Your weekly-report and plateau-detection crons process users one at a time in a single 30-second request. Works for 30-50 users today; at 100+ the job will time out before reaching everyone, and some users silently stop getting their reports.

1. Move per-user work into a Cloudflare Queue or Supabase pg_net background job - cron handler enqueues a task per user, returns immediately.
2. Add a resume cursor (last_processed_user_id).
3. Split by time-zone bucket so each hourly cron tick processes only users whose local time matches.
4. Immediate-term: Promise.all-with-limit (p-limit, batch of 5-.
5. AND a hard time budget that returns 200 with summary processed/remaining.
6. Observability: log start/end timestamp and remaining; alert when remaining > 0.

L — 1–2 weeks

• https://developers.cloudflare.com/queues/
• https://supabase.com/docs/guides/database/extensions/pg_net
• https://github.com/sindresorhus/p-limit

Cost scaling is essentially linear-in-bad-actor: a single authenticated user with a script (or buggy frontend re-firing on keystrokes) can spawn dozens of parallel openai/gpt-5 calls. No application-level circuit breaker - only the gateway 429 (caught and surfaced, but not used to throttle subsequent attempts). Combined with SCA-001 and SCA-002, a user firing 50 messages in 5 minutes can consume $5-10 of credit; an attacker bypassing dedup with varied content can consume orders of magnitude more. No usage attribution: when the bill arrives there is no way to identify which users drove it.

Direct dollar cost: a single power user can cost $10-50/day; a malicious script with one stolen session token can cost $100-1000/day. With no per-user budget the only ceiling is the prepaid Lovable credit balance, drainable in hours. Lack of usage attribution makes post-incident triage impossible.

There is no spending cap per user on AI calls. One user, one bug, or one bad actor can fire many AI calls in parallel and drain your AI credit balance. You also have no way to see which user is driving cost.

1. Add a database monthly budget per user in profiles (monthly_ai_tokens_used INTEGER, monthly_ai_tokens_limit INTEGER).
2. Wrap every AI gateway call site in a chooseAndCallAI(userId, model, request) helper that checks the budget, reads the usage block, increments monthly_ai_tokens_used, and logs to an ai_call_log table for attribution.
3. Add an organisation-wide circuit breaker via a Durable Object counter.
4. Surface remaining quota in the UI.
5. Stream usage events so cost is recorded in real time.
6. Cache deterministic prompts (e.g. relocalize).

L — 1–2 weeks

• https://platform.openai.com/docs/guides/prompt-caching
• https://developers.cloudflare.com/durable-objects/
• https://platform.openai.com/docs/api-reference/usage

Several of these images are likely mockups only used on marketing screens (or unused after a UI iteration). On a 4G connection 8 MB of images = ~15-20 seconds of perceived sluggishness. Image bytes are NOT bundled into the Worker (served as static assets) so this is a client-bundle and CDN-cost concern, not a Worker-size issue.

Slower perceived performance for mobile users (chief target persona). ~2 MB per mockup means each marketing screen takes 3-5 seconds to render on typical 4G. CDN egress costs scale with bytes: 1000 visits/day to a 1.5 MB PNG screen = 1.5 GB/day. If any mockup PNGs are not referenced from current routes, they are pure dead weight.

Your app ships mockup images at 1.5-2 MB each in raw PNG. On a phone over cellular each one takes a few seconds to load. Converting to WebP/AVIF and lazy-loading below-the-fold images would cut this substantially.

1. One-time pass with squoosh-cli or sharp to convert PNG mockups to WebP at 85% quality (typical 70-90% reduction).
2. Add vite-imagetools or vite-plugin-image-optimizer to vite.config.ts.
3. Audit each src/assets file - delete any not imported anywhere.
4. Add loading=lazy decoding=async to every below-the-fold img tag.
5. Use picture element with WebP + AVIF + PNG fallback and responsive srcset for hero images.
6. Add CI bundle-size check that fails when individual assets exceed 500 KB.

M — 1–3 days

• https://github.com/JonasKruckenberg/imagetools
• https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video

Without explicit Cache-Control: public, max-age=31536000, immutable on fingerprinted assets, Cloudflare CDN behaves conservatively - every cold-cache request hits the origin Worker, increasing CPU billing and worsening cold-start exposure. The HTML SSR response has no Cache-Control either. Sensitive endpoints should be marked no-store explicitly to avoid intermediate cache mishaps - they are not.

Higher Cloudflare Worker invocation count and CPU time, because every static asset request goes through the Worker instead of being served from edge cache. At 1000 daily visitors loading 20 assets each = 20,000 extra Worker invocations per day. The HTML page being uncached prevents auto-minification and brotli cache hits.

Your app does not tell browsers and Cloudflare how long to cache things. Every visitor re-downloads every image, font, and CSS file on every visit. Adding standard cache headers is a 30-minute change that reduces both your traffic and your visitors load time.

1. Add a public/_headers file (Cloudflare Pages-style) or header-injection middleware in src/start.ts. Recommended rules: /_app/* with Cache-Control: public, max-age=31536000, immutable; /assets/* with public, max-age=86400, stale-while-revalidate=604800; /api/* with no-store; / (landing) with public, max-age=300, stale-while-revalidate=3600.
2. Verify with curl -I that Vite fingerprinted assets get the immutable header.
3. SSE endpoints: explicit Cache-Control: no-store, no-cache, must-revalidate.

S — under ½ day

• https://developers.cloudflare.com/pages/configuration/headers/
• https://web.dev/articles/http-cache

select(*) fetches every column including large JSON columns (ai_analysis blobs can be 1-5 KB each, zone_minutes JSON on biometrics). For meals limit 20 that is ~60 KB of unused JSON per dashboard mount. Compounds with React Query refetch on focus and the in-component useEffect refetch on data-change events. On slow mobile, dashboard mount spends a noticeable fraction of time fetching bytes the component never reads.

Slower dashboard TTI on cellular networks, higher Supabase egress cost, noisier Postgres query plans (column list affects index-only-scan eligibility). Not critical today, but a multi-hundred-megabytes-per-day waste at 1000-DAU scale.

Your dashboard downloads every field of every record from the database, even fields it never displays. For some users that is 30-100 KB of wasted data per page view. Changing select(*) to a named column list is a 15-minute fix per query.

1. Replace select(*) on biometrics with the explicit column list already in the Biometric interface.
2. Replace select(*) on meals with the Meal interface column list.
3. For ai_analysis specifically, do not load it on the dashboard - load on demand in MealDetailSheet.
4. Repeat for subjective_pulse (only energy/stress/soreness used).
5. Add ESLint rule or CI grep flagging new .select(*) usages.

S — under ½ day

• https://supabase.com/docs/guides/api/quickstart
• https://www.postgresql.org/docs/current/indexes-index-only-scans.html

At year-2 scale (10-40M rows per hot table) the user-id-scoped queries are still index-efficient (logarithmic), but the supporting RLS policies execute auth.uid()::text comparisons on every row a candidate query touches. Postgres planner stats degrade without ANALYZE. No retention means historical data accumulates forever even when users never read it. Auto-vacuum becomes a concern past ~50M rows. Backup size grows linearly.

At year-2 scale: Supabase Pro storage is included up to 8 GB; with multi-tenant logs the database will cross that threshold and start charging $0.125/GB/month. Backup snapshots compound storage cost. Query latency degrades modestly: p95 dashboard load goes from ~200 ms today to ~500-800 ms at year 2. Any future schema migration on a 40M-row table requires careful planning.

Several of your busiest tables (chat messages, meal logs, habit logs) will keep growing forever - your app has no cleanup or archive policy. At 1000 daily users for a year those tables hold tens of millions of rows. Today this is fine; in 18-24 months it starts costing real money in storage and slowing queries.

1. Author retention policies per table: coach_messages > 365 days -> archive table; meals > 730 days -> drop ai_analysis column; lifestyle_logs > 180 days -> aggregate to daily rollup.
2. Implement as Supabase pg_cron jobs running weekly.
3. Add EXPLAIN ANALYZE to representative dashboard queries; ANALYZE the tables if planner is stale.
4. Add (user_id, created_at DESC) compound index to coach_messages (current index does NOT help the user-scoped query in SCA-004).
5. Monitoring alert when any table > 5 GB.
6. Long-term: consider partitioning hot tables by month.

M — 1–3 days

• https://www.postgresql.org/docs/current/ddl-partitioning.html
• https://supabase.com/docs/guides/database/extensions/pg_cron
• https://gdpr-info.eu/art-5-gdpr/

Each createClient instantiates a fetch-based PostgREST client - relatively cheap (1-2 ms) but not free. On Workers each isolate is reused for many requests; per-request instantiation misses connection state and HTTP/2 stream reuse. Critical risk: if SUPABASE_URL points at the direct Postgres endpoint instead of the pooler, every request opens a new pooled connection - direct endpoint caps at max_connections (60 Pro, 200 Team) while the pooler supports thousands.

Small CPU overhead per request - multiplied by every API call and cron iteration. More importantly the architectural risk: if SUPABASE_URL is the direct host instead of the pooler, the project hits max_connections at modest concurrency with random too many connections errors. Verification step: confirm SUPABASE_URL contains pooler.supabase.com (transaction-pooler mode) for serverless.

Your code creates a fresh database client on every request and every cron iteration instead of reusing one. The cost per request is small, but the pattern can become a problem under load. Also please verify the database URL in your environment uses Supabase connection pooler (a URL with pooler in the hostname) - without it you can hit a hard ceiling on simultaneous database connections.

1. Refactor cron handlers (body-plateau-detect.ts, weekly-reports.ts) to import supabaseAdmin from @/integrations/supabase/client.server instead of constructing a new client.
2. Verify SUPABASE_URL in the Cloudflare environment is the pooler URL (Supabase dashboard -> Settings -> Database -> Connection Pooler, port 6543 transaction mode for serverless).
3. Document the requirement.
4. Add a /api/_health endpoint that verifies the URL contains pooler so misconfiguration is caught in CI/staging.

S — under ½ day

• https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pooler
• https://www.pgbouncer.org/

Without a bundle budget there is no early signal when a new dependency pushes the Worker bundle past Cloudflare 10 MB compressed limit. Current dependency mix is well within today budget but trending upward. The home route being explicitly NOT code-split means the entire landing renders in the critical chunk. lucide-react can balloon if imported as import * as Icons from lucide-react - needs verification.

Risk-only at current scale. The bundle is probably 3-5 MB compressed today and the 10 MB limit is far. But a single careless import * as Icons from lucide-react or adding a heavy chart library would breach the limit silently, and the team would learn at deploy time. From a Worker startup angle, parse time scales with bundle size: larger bundles = longer cold-start (50-150 ms cold vs 1-5 ms warm).

There is no automatic check on how big your shipped JavaScript bundle is. As new features and libraries are added the bundle silently grows until a deploy fails because Cloudflare 10 MB limit was crossed. Adding a simple size-check catches this early.

1. Add rollup-plugin-visualizer to vite.config.ts so each build produces dist/stats.html.
2. Add npm script analyze that opens the report.
3. Once CI exists, use size-limit to fail the build if main chunk grows by more than 10% week-over-week or Worker bundle > 6 MB compressed.
4. Audit lucide-react import sites - ensure they use the recommended named-import form.
5. Investigate whether codeSplittingOptions excluding the home route is justified - the home page benefits most from code-splitting.

S — under ½ day

• https://github.com/btd/rollup-plugin-visualizer
• https://github.com/ai/size-limit
• https://developers.cloudflare.com/workers/platform/limits/#worker-size

Per-avatar generation potentially costs 4-8x more than necessary. With the 8-image bank per user (TOTAL_BANK_VARIATIONS = 8), every new user triggers 8 image generations at this ceiling - meaningful at 1000+ signups. The historical bank size was 160 (comment line 26), so this code was previously 20x more expensive - the team optimised that but missed the per-call ceiling.

Per-user signup cost on the image generation pipeline is higher than necessary by an estimated 2-4x. At 1000 signups, a marginal cost difference but predictable savings. At high signup-spike traffic (e.g. marketing campaign), the unconstrained per-call cap makes spike cost harder to forecast.

The Bio Twin avatar generation requests the maximum response size from the AI even though it does not need it. Setting a lower cap (1024 instead of 8192) cuts the per-image cost without changing the output quality.

1. Reduce max_completion_tokens on image-generation calls (bio-twin-avatar.ts:194, 356; bio-twin-bank-generator.ts:.
2. to 2048 or 1024.
3. Add an explicit comment justifying whatever value is chosen so future devs do not bump it up reflexively.
4. Test with the lower cap to confirm quality is unchanged.

S — under ½ day

• https://ai.google.dev/gemini-api/docs/image-generation