How the work connects
I own all three, from the first sketch to launch.
See how a project runs1–2 weeks
Discovery, stakeholder interviews, and a written scope. You sign off on cost and dates before any code.
Two-week sprints
Planning, development, code review, and QA every sprint, closed with a report on what shipped.
UAT to production
You click through each feature in UAT. Approved releases reach real users with zero downtime.
Where you come in
Join at whichever stage you are at. Every path ends at ship.
Starts at plan
From proposal to first users.
Turn a proposal into software the first users can actually book, pay, or log into.
You bring
A proposal and the users it is for
You leave with
I choose the stack for the project, not out of habit.
The Track Booking Platform is Next.js and React on a Django API. The Sports Team App is Angular and Ionic on NestJS and Firestore. Different answers for different products, both running in production.
I work across the frontend, the API, the database, and the AWS account underneath, so nothing has to change hands between them.
Stack by project
Picked per product
01Interface
02API
03Data
04Cloud & payments
5white-label venues on one platform
Four layers, one engineer.
No handoffs between them.
I build on Lambda, Cognito, Amplify, and DynamoDB, deployed as one SAM stack. The memorial planning portal runs on that stack and handles 500+ authenticated requests a day.
Every request is traced hop by hop, so when checkout slows down, I can see which service caused it.
I build product UI in Next.js and React. The Track Booking Platform's white-label booking sites run five race tracks from one codebase. Each venue gets its own brand, domain, and pages, while calendars and checkout stay shared.
I ship mobile apps with Ionic, Angular, and React Native. The Sports Team App runs web and mobile from one codebase, so coaches and players see the same live schedule.
Postgres holds the relational records. DynamoDB and Firestore take over when a product needs partitioned writes or live sync. Queries run against those same stores, so AI answers come from live data, not a copy.
Stripe and Trust Commerce write to the same store that owns the record. I set that up at the schema level, so a payment and its record can't drift apart.
Booking flows, payment rails, live rosters. Tell me what you're shipping and where it needs to land.