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 decision.
Software background
I spent five years as an engineer at startups, shipping product features, internal tools, workflows for customers, and the data models underneath them.
At LeagueSide, later acquired by TeamSnap, I worked across the 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. Those stacks 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 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 was a marketplace that connected fighters for sparring. 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 a data foundation of real gyms, real locations, and real training information 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: a searchable, filterable city directory that lists the gyms in one city, and structured gym profiles covering training types, pricing, visitor access details, amenities, and contact links. Browsing is a list today; the map view is marked “soon” in the product and hasn't shipped. 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. I chose this stack for type safety, fast iteration, and a database 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 across the stack, from schema to deployed UI, and where product judgment matters as much as implementation.
See the flagship project
The full story of JabNGo, including the problem, scope, and technical decisions.