Joey Hershkop

The Problem

Traditional family software often assumes a simplistic nuclear household: two parents at a single residential address. In reality, modern families have diverse structures—divorced co-parents living at different addresses, step-parents, grandparents, and legal guardians who all need shared access to manage children's schedules, registrations, and medical emergency details.

Reggeee was conceived as a two-sided marketplace for children's activity businesses and families. The engineering challenge was taking an early conceptual idea and building a production-grade foundation: a resilient relational schema, secure authentication, and an extensible API-first architecture.

What I Owned

I established the technical foundation across the entire stack:

• Relational Domain Modeling: Designed and documented the complete PostgreSQL schema for identity, multi-adult families, children, businesses, offerings (class series vs. single parties), and registrations.
• Hardened Authentication & Session Layer: Implemented parent signup, login, and session restore using Argon2id password hashing, HttpOnly cookie transport, Redis live token storage, and SHA-256 hashed audit records in PostgreSQL.
• Parent & Family Vertical (Live Slice): Built the end-to-end flow for family creation, child profiles, adult invitation tokens (via shareable short-code URLs), acceptance/decline lifecycles, and primary contact reassignment upon member leave.
• Contract-Neutral Frontend Architecture: Rebuilt the frontend in React 19 and TypeScript with Tailwind CSS, TanStack Query, Radix UI primitives, and domain adapters that decouple internal UI components from evolving API DTOs.
• Multi-Layer Testing: Authored PHPUnit integration suites, Vitest component and accessibility (axe) tests, and Playwright end-to-end tests against the live API.

The Interesting Engineering

1. Modeling Multi-Adult Family Invariants

Rather than coupling children to a single household address or capping guardians at two, the family model treats the Family as the central operational unit:

• Unlimited active adults per family with equal administrative visibility over children.
• Polymorphic addresses cleanly separated across businesses, families, and emergency contacts.
• Preservation of child records if a parent leaves a family unit, ensuring historical registrations and health disclosures remain intact.

2. Security-First Auth & Anti-Enumeration

Account security was engineered to prevent timing-based user enumeration:

• Constant-Time Execution: When a user attempts to log in with an unrecognized email, the backend executes a dummy Argon2id verification with a precomputed hash to maintain identical timing profiles.
• Uniform Error Responses: Missing users, incorrect passwords, and inactive accounts return identical 422 error structures.
• Zero Raw Token Persistence: Live session tokens exist only in Redis with sliding TTLs; PostgreSQL stores only a one-way SHA-256 hash for historical audit logging.

3. Contract-Neutral Frontend Adapters

To prevent the frontend from hardcoding speculative backend endpoints or coupling UI components directly to raw API response shapes, I built a typed adapter layer. The React application binds to domain-level entities, allowing backend data models to evolve without triggering cascading UI rewrites.