Direction

Plan and Direction

Where Lumenal is going and in what order. The work runs on four tracks that can move mostly in parallel: platform (get off Lovable's stack), revenue (turn on payments), mobile (pick a concept, then build it natively), and brand/design (choose and apply a direction). The confirmed strategic decisions from July 10 anchor everything here.

Confirmed direction (decided 2026-07-10)

Migrate the backend to AWS-native services (Aurora, Cognito, S3, API Gateway — not self-hosted Supabase), and replace the Lovable AI gateway with the direct Google Gemini API, keeping the same models. The phased migration sequence lives in docs/index.html, which remains the canonical architecture document.

Track 1 — Platform: off Lovable, onto AWS

The web app is Lovable-authored and runs on Lovable's Supabase project and AI gateway. Both are exit risks and cost opacities. The CDK scaffold in infra/ (Network, Database, Auth, Storage, Api, WebHosting stacks) is synth-verified but not deployed.

  1. Now: rotate the dev credentials exposed in docs/README.md (standing P0), and swap edge functions from the Lovable gateway to direct Gemini API keys — small change, removes the tightest coupling.
  2. Next: deploy the CDK stacks to a staging account; stand up Aurora and migrate the schema; dual-write or snapshot-cutover the data.
  3. Then: move auth to Cognito (the riskiest step — password migration needs a lazy-migration proxy), repoint the frontend, retire the Supabase project.

Track 2 — Revenue: finish payments

The order/cart/product schema is complete in the database, but no checkout exists — the platform currently cannot take money. This is the single highest-leverage engineering task and it does not depend on the AWS migration.

  1. Stripe checkout for shop orders (cards + wallets), then order-status webhooks.
  2. Luxury report purchases as one-off Stripe payments gating generation.
  3. Subscription plumbing follows once the monetization model is decided (see Decisions).

Track 3 — Mobile: concept first, then native build

The Expo app (lumenal_expo) is a Phase-1 skeleton with its work uncommitted on feature/env-config. Rather than grinding through the 22-week spec for a design nobody has validated, the plan is:

  1. Now: run the focus group on the three concept apps (Mobile Test Apps) — 2-3 weeks including rotation.
  2. Next: pick the winning concept, fold the runner-up's best feature in, and rewrite the Phase 1-2 mobile spec around it.
  3. Then: build it natively in lumenal_expo against the post-migration API. First: commit the existing skeleton work.

Track 4 — Brand and design

  1. Choose the desktop direction from the three comps (recommended pairing: Atelier marketing surface + Sanctuary logged-in app + Observatory as the Chart section).
  2. Extract the chosen direction into a design-token package shared by web and mobile (the mobile strategy doc already defines the token bridge).
  3. Apply to the web app screen-by-screen, starting with landing and dashboard.

Sequencing at a glance

HorizonPlatformRevenueMobileDesign
Weeks 1-3Rotate creds; direct Gemini swapStripe checkout buildFocus group runsPick direction
Weeks 4-8Deploy staging stacks; DB migrationReport purchases; webhooksWinner chosen; spec rewriteToken package; landing + dashboard
Weeks 9-16Cognito cutover; retire SupabaseSubscription launchNative build Phase 1-2Remaining screens
Guiding principle

Every track has one question it must answer before spending big: platform — "can we serve a reading end-to-end off AWS?"; revenue — "will someone pay?"; mobile — "which concept do people return to?"; design — "which direction do we commit to?". Spend on validation first, volume second.