The Problem
A multi-area marketplace becomes hard to operate when commerce, events, donations, directory listings, subscribers, users, messages, and analytics each have their own operational needs. Staff need one coherent control plane that protects private data while still giving enough visibility to run the platform.
This case study describes the operations layer without publishing admin screenshots, user records, analytics rows, production endpoints, or infrastructure identifiers.
What I Built
I classified this as a third project slice because the inspected codebase has more than customer-facing commerce and event flows. It includes a broad admin shell, protected APIs, revenue views, analytics capture/reporting, directory management, donation/contact workflows, uploads, and maintenance-mode support.
Project Overview
This is a private client platform. The public case study uses sanitized architecture and workflow summaries.
My Contribution
- Built admin surfaces for users, events, products, orders, tickets, donations, contacts, directory listings, subscribers, revenue, analytics, and check-in tooling.
- Centralized admin data access through TanStack Query hooks and mutation invalidation patterns across the operations console.
- Implemented first-party analytics persistence and reporting surfaces for sessions, pageviews, custom events, web vitals, errors, traffic sources, devices, countries, and realtime activity.
Operations Map
Staff operations control plane
The admin console coordinates cross-platform workflows without exposing private production data in this public case study.
Diagram uses generic module labels and excludes records, URLs, account identifiers, and admin screenshots.
Technical Decisions
Unify staff operations in one console while keeping domain data boundaries intact.
- Products, orders, events, tickets, donations, directory listings, subscribers, revenue, and analytics each have different rules but need one staff-facing workflow.
- The admin hook layer becomes broad and needs clear query keys, mutation invalidation, and privacy-sensitive reporting boundaries.
- Staff get one operations surface while backend routes and persistence models stay organized by domain.
How I Work
Engineering Challenge
- Operations software is dense, and a public portfolio can accidentally reveal too much.
- I separated publishable architecture from private data by reviewing admin routes, hooks, models, migrations, pages, and docs without copying records or deployment identifiers.
- The case study focuses on module boundaries, auth-gated operations, revenue separation, analytics models, and maintenance behavior.
- The public story shows platform engineering depth while withholding private admin data and infrastructure details.
Quality & Testing
Quality Evidence
Product engineering evidence
- Private source includes admin pages, hooks, protected routers, analytics models, migrations, directory/donation/contact/subscriber areas, Docker service shape, and deployment workflow evidence. No public test totals are claimed.
- Private CI/CD and infrastructure docs were reviewed only for generic service shape; logs, resource identifiers, domains, account IDs, and env values are not published.
- Source evidence verifies Next.js, React, TypeScript, FastAPI, PostgreSQL, TanStack Query, AWS service shape, admin auth, analytics persistence, revenue APIs, uploads, and maintenance middleware.
Public page quality
- The public visual is a recreated SVG with accessible title and description.
- The diagram uses scalable SVG geometry inside the shared case-study layout.
- No admin screenshots, real user records, analytics rows, production URLs, credential details, or infrastructure identifiers are bundled.
| Area | Evidence | Published detail |
|---|---|---|
| Admin shell | Admin layout, sidebar, pages, and hooks | Generic operations console |
| Observability | Analytics models, provider, admin analytics page, reporting routes | First-party analytics shape |
| Platform ops | Revenue, directory, donations, contacts, subscribers, uploads, maintenance middleware | Cross-platform staff workflow |
Results & Impact
This slice demonstrates platform engineering beyond feature pages: auth-gated staff tools, admin data-fetching patterns, revenue breakdowns, analytics storage and reporting, content/directory management, subscriber workflows, uploads, and operational maintenance behavior.
What I Learned
The more a product grows, the more valuable the quiet admin layer becomes. Good operations tooling turns scattered workflows into a control plane that staff can trust without asking engineers to inspect the database.