Platform Update (2026-02): Architecture, App Status, Roadmap

This is the first longer update since the last post on 2025-12-25. The goal of this write-up is to (1) document the architecture and setup we’ve achieved so far, (2) refresh the status of each deployed subdomain, and (3) lay out a practical roadmap for the next stretch.

Architecture Snapshot (How The Platform Is Put Together)

At a high level:

• platform.sg is the home site and blog (Cloudflare Pages).
• Most user-facing apps live under *.platform.sg (Cloudflare Workers/Pages and/or Render).
• A shared backend service consolidates “platform-grade” concerns and cross-app APIs.

A simplified view of the request flow:

1. User visits *.platform.sg (edge-hosted UI).
2. The app uses shared login via oauth.platform.sg (SSO).
3. For shared APIs, edge services call the shared backend with app-scoped auth (x-app-id) and a shared bearer token.
4. Specialized services (example: payments) sit behind the shared backend where needed.

This structure lets us keep the edge thin while consolidating correctness, data access, and contracts in a single shared backend over time.

Deployed App Status (Current Snapshot)

App	Status	What it’s trying to achieve
Housing	Live	A fast transaction explorer with map + filters + trends.
Services	WIP	Provider-first booking with public profiles + provider dashboard.
Household	WIP	Household operations: tasks, schedules, and daily routines.
Drivers	WIP	Structured reporting + discussion with moderation-first design.
Seniors	Live	Seniors Help: request help, volunteer, coordinate care.

What We’ve Achieved Since 2025-12-25

Platform setup

• A real home site + blog under platform.sg, with a CMS editor UI (/admin) for updating content.
• A consistent “projects directory” that can act as a public-facing index of what’s live and what’s in progress.

Shared primitives

• Standardized SSO integration across apps (oauth.platform.sg), with a consistent pattern for “public landing + gated app routes”.
• A shared backend service direction: migrate read-heavy and cross-app contract endpoints into one place, while leaving app-specific UI/product logic at the edge.

Migration approach

• A practical promotion path for migrated routes (legacy -> shadow -> strict) so we can move endpoints safely without big-bang rewrites.
• Smoke checks and runbooks to make cutovers repeatable.

Roadmap (Next 30/90 Days)

Stabilize what’s already deployed (30 days)

• Keep the project directory aligned with active apps (Helpers merged into Household; Workout retired) and add redirects so old links keep working.
• Reduce deployment footguns: eliminate worker name collisions across worktrees vs canonical apps.
• Ensure every “live” app has:
  • a clear public landing page
  • a clear login boundary
  • a basic health check and smoke probe path

Move more shared APIs into the shared backend (90 days)

• Continue migrating read-heavy endpoints where it reduces cost/complexity and improves reliability.
• Keep app-owned write/admin surfaces app-local until the shared backend contracts are ready.

Product-facing momentum

• Services: harden booking lifecycle + operational workflows.
• Seniors: refine volunteer/admin operations and reliability.
• Household: build out the “core household loop” (tasks/schedules) and keep auth/payments consistent.
• Drivers: invest in moderation, safety, and policy before broadening access.

Closing Notes

If you’re using any of the live subdomains and run into rough edges, the most useful feedback is:

• what you were trying to do
• what you expected
• what happened instead
• the URL and time it occurred