Treaty (MVP)

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.

UP NEXTSequential Deep Dive
Industry: Faith-Based / Campus Ministry Operations | CLIENT: Word Study Chaplaincy (Architect Endurance Word Study) | PROJECT: Automated Telegram Dispatch Bot

Word Study Dispatch Bot

Automated Telegram alerting system that eliminated redundant manual new-member dispatches and instituted a timestamped Google Sheets audit log.

NEXT PROJECT