About
A product engineer who builds the whole thing.
I care about the path from a real problem to a working product.The data model, the interface, and the decisions in between. This site is where I document JabNGo as I build it: the product choices, technical tradeoffs, and the thinking behind the work.
Who I am
I'm a software engineer who cares about real problems and practical products. I'm not interested in building things just to say I built them. I want what I ship to matter to the people using it. That means knowing what to cut, what to keep, and how to explain the decisio
Software background
I spent five years as an engineer at startups, shipping product features, internal tools, customer-facing workflows, and the data models underneath them.
At LeagueSide, later acquired by TeamSnap, I worked full-stack on sponsorship and scheduling products serving youth sports organizations. At Mavrck, I built creator-marketing platform features across the web app and supporting data services. That work ran on React, Ruby on Rails, GraphQL, Postgres, AngularJS, and AWS Lambda/SQS — stacks that taught me how to ship inside real constraints and stay effective across frontend, backend, and product surfaces.
Boxing / athletic identity
I' ve been training in boxing for several years. The sport has a feedback loop most activities don't — you find out quickly whether your technique works. That shapes how I think about building: repetition matters, honest feedback matters, and there is no shortcut to earning skill over time.
Boxing is also where JabNGo started. It is not the whole story of the product, but it is why I understood the problem firsthand.
How JabNGo started
Finding a serious boxing gym — one with real coaches, structured training, and a culture worth being part of — is harder than it should be. When you're traveling or in a new city, you're usually piecing information together from Google Maps pins, Instagram pages, old websites, WhatsApp messages, and word of mouth.
The information exists. It's just scattered, inconsistent, and often outdated. That gap is what JabNGo is trying to close.
Why it shifted from a sparring marketplace to gym discovery first
The original idea had more marketplace energy — connecting fighters for sparring, building around matching. But the more I thought about the user's actual journey, the clearer it became that gym discovery was the right first wedge.
Discovery is easier to validate. It helps more users immediately. It creates useful public pages that work for SEO. And it builds the data foundation — real gyms, real locations, real training info — that any future feature like reviews, events, sparring, or gym claims would need anyway.
The marketplace can come later. The directory comes first.
What I'm building now
JabNGo V1 is focused on the discovery layer: city pages, gym detail pages, structured training information, drop-in details, and map/list views for browsing. The goal is the smallest thing that's genuinely useful to a fighter looking for a place to train.
The current stack is Next.js, TypeScript, React, Prisma, Postgres, and Vercel — chosen for type safety, fast iteration, and a database-backed foundation that can grow beyond static pages.
What I'm working toward
Right now I'm focused on turning JabNGo into a real product and using this site to document the thinking behind the build — not just the final screens. That means publishing real gym data, writing about decisions as I make them, and building public proof of work.
Long term, I’m aiming for engineering environments where I can build end-to-end — from schema to deployed UI — and where product judgment matters as much as implementation
See the flagship project
The full story of JabNGo — problem, scope, and technical decisions.