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.
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.
- 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. - Next: deploy the CDK stacks to a staging account; stand up Aurora and migrate the schema; dual-write or snapshot-cutover the data.
- 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.
- Stripe checkout for shop orders (cards + wallets), then order-status webhooks.
- Luxury report purchases as one-off Stripe payments gating generation.
- 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:
- Now: run the focus group on the three concept apps (Mobile Test Apps) — 2-3 weeks including rotation.
- Next: pick the winning concept, fold the runner-up's best feature in, and rewrite the Phase 1-2 mobile spec around it.
- Then: build it natively in
lumenal_expoagainst the post-migration API. First: commit the existing skeleton work.
Track 4 — Brand and design
- Choose the desktop direction from the three comps (recommended pairing: Atelier marketing surface + Sanctuary logged-in app + Observatory as the Chart section).
- Extract the chosen direction into a design-token package shared by web and mobile (the mobile strategy doc already defines the token bridge).
- Apply to the web app screen-by-screen, starting with landing and dashboard.
Sequencing at a glance
| Horizon | Platform | Revenue | Mobile | Design |
|---|---|---|---|---|
| Weeks 1-3 | Rotate creds; direct Gemini swap | Stripe checkout build | Focus group runs | Pick direction |
| Weeks 4-8 | Deploy staging stacks; DB migration | Report purchases; webhooks | Winner chosen; spec rewrite | Token package; landing + dashboard |
| Weeks 9-16 | Cognito cutover; retire Supabase | Subscription launch | Native build Phase 1-2 | Remaining screens |
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.