← ALL WORK
WRK//0022024 to now
Zenith Kids Platform.
The full technology stack for a 501(c)(3) youth nonprofit I founded: public site, web app, Rust API, email service, and a native iOS app.
ROLE
Founder and sole engineer
STATUS
Site live, platform in beta
FOR
Volunteers, families, tutors, and staff
YEAR
2024 to now
The problem.
Zenith Kids is a nonprofit I founded that supports vulnerable youth in Charlotte and Middle Tennessee. Nonprofit software is usually a pile of spreadsheets, six SaaS subscriptions, and a prayer. I wanted the organization to run on one coherent platform, so I built it.
Serving minors raises the bar on everything. Age gating, guardian consent, data privacy, and auditability are not features you bolt on later. They shape the whole architecture.
What I built.
- A Rust backend with roughly 226 route handlers across 39 versioned modules: volunteering, events with QR check-in, tutoring, donations, messaging, and staff administration. 181 SQL migrations, every one reversible, and CI proves the round trip on every push.
- Role-based access control defined as a Rust enum of about 50 permissions, mirrored to the database and synced on boot. If code and database disagree in production, the server refuses to start. I would rather have a failed deploy than a silent permission hole.
- A native SwiftUI iOS app, about 39,600 lines of Swift with zero third-party dependencies. Sign in with Google is hand-implemented OAuth with PKCE rather than an SDK import. Concurrent token refreshes coalesce into a single flight. Keys live in the Keychain, device-bound.
- A volunteer time clock that closes the loop: scan a QR ticket at the door to check in, scan again to check out, and hours are awarded automatically with an idempotency guard so nobody double-dips.
- The public site at zenithkids.org, live today, with privacy-first analytics that send nothing until a visitor consents, and advertising signals permanently disabled because the audience includes families and kids.
- A separate stateless email microservice reachable only over internal networking, authenticated with HMAC-signed requests carrying timestamps and replay-guarded nonces.
Engineering notes.
- Passwords hashed with Argon2id at OWASP-recommended parameters; a detected refresh-token replay revokes every session for that user
- Sensitive PII encrypted at rest with AES-256-GCM under domain-separated keys, so one compromised key category leaks nothing else
- COPPA-aware account model: under-13 accounts are guardian-managed with no login credentials at all, and age checks are always computed server-side
- Audit log records every state-changing operation with actor, target, and before/after snapshots
- CI runs formatting, clippy with warnings as errors, tests against live Postgres and Redis containers, cargo audit, and gitleaks secret scanning on every push
- Staff access to sensitive records is break-glass by design: it requires a narrow permission plus a written reason, and always writes an audit row
NEXT // WRK//003
Martha's Mission