Platform Update (2026-02-16): UI Kit Rollout, Seniors Marketplace Progress

This is a quick follow-up to yesterday’s write-up (2026-02-15) to capture what’s changed since then, and to keep the “what is live vs WIP” picture accurate.

What We Shipped Since 2026-02-15

1) Consistent UI chrome across apps

We stabilized and rolled out the shared UI shell (@platformsg/ui-kit) so each app can look and behave consistently without reinventing layout, tokens, and header patterns.

The goal is simple: when you switch between subdomains, the experience should still feel like one platform.

2) Services: migrated to the shared shell

The Services web app now uses the shared PlatformShell while keeping its own email OTP login flow. This gives us a consistent header/nav without forcing all apps into one auth implementation.

3) Seniors: public browsing (privacy-safe)

Seniors now supports signed-out public browsing of open tasks (view-only):

• People can browse what’s available without creating an account first.
• Location remains redacted by default to keep seniors safe.
• Signing in is still required to make offers and progress tasks.

This is a key step toward an Airtasker-style “requests + offers” marketplace flow.

Architecture (Still The Same Shape, Cleaner Edges)

The overall structure is unchanged from the 2026-02-15 post, but we’re steadily tightening the integration boundaries:

graph TD
  U[User] --> UI[Apps: *.platform.sg]
  UI -->|SSO login| O[oauth.platform.sg]
  UI -->|/api| A[App API worker/service]
  A -->|select routes| PB[platform-backend /v1/*]

The practical direction is:

• Keep product UI and app-specific logic at the edge.
• Consolidate “platform-grade” contracts and shared concerns into the shared backend over time.
• Use stable tokens + shell primitives so UI consistency doesn’t require a monorepo rewrite.

Roadmap (Next Slice)

Seniors marketplace transition

• Define the MVP PRD + state machine for the marketplace flow (request -> offers -> accept -> task lifecycle).
• Keep “seniors-first safety” as a hard constraint (privacy redaction, verification tiers, admin tooling).
• Make it sustainable: design the incentives/fees model even if we defer implementation.

Services

• Harden booking lifecycle (cancellations, reminders, operational visibility).
• Begin extending payments/reconciliation once the lifecycle is stable.

Platform

• Keep the projects directory and blog current as apps evolve (so external updates don’t lag behind reality).