A deliberately scoped backend foundation — authentication, server-verified payments, and Row Level Security — engineered for a clean client handoff.
01 // THE OBJECTIVE
The Problem & Architecture Mandate
Treaty's MVP phase was about establishing a secure, monetized foundation — authentication, payments, and database security — that a client could hand off and build further features on top of. My role was Initial Framework & Backend Architect: laying the groundwork, not the full product build.
02 // ARCHITECTURAL APPROACH & EVOLUTION
Engineering Iterations & Milestones
Phase 01Production Milestone
Authentication & Route Protection
Implemented Clerk for identity management, with a global middleware guard restricting access to core routes (dashboard, finance, food, fitness, schedule) until a user is authenticated.
Phase 02Production Milestone
Verified Payments
Built server-side payment verification with Paystack — rather than trusting client-side confirmation — independently checking each transaction before granting access, then calculating subscription expiry automatically.
Phase 03Production Milestone
Locked-Down Data
Applied Row Level Security in Supabase so users can only ever query their own subscription data, with generated TypeScript types keeping frontend and backend in sync.
Phase 04Production Milestone
Deliberate Scope Cuts
Removed Group Plans and per-module pricing in favor of one simple, individual time-based subscription that unlocks the whole app — and intentionally left out an internal wallet system in favor of straightforward transaction tracking.
03 // ARCHITECTURAL CONCLUSION
System Longevity & Durability
The Treaty MVP is a secure, functioning foundation — not a finished consumer product yet, but a deliberately scoped backend and auth layer built to be extended rather than reworked.
04 // THE RESULTS
The MVP is live and fully functional, with real authentication, real payment verification, and real database security in place — but it hasn't been used by real customers yet, since the client is taking it forward from here. The honest result of this phase isn't usage numbers; it's a clean handoff: working infrastructure, clearly documented architectural decisions (like keeping middleware.ts named against Next.js's own deprecation guidance because Clerk requires it), and a scoped-down feature set that won't need to be torn up later.