Original concept
Sparring marketplace
- Requires active supply and demand
- User accounts and profiles
- Identity and trust concerns
- Scheduling and coordination
- Difficult cold start
- Safety and moderation requirements
Product engineering case study
JabNGo is a boxer-first gym directory that turns scattered, inconsistent gym information into searchable, comparable listings. I designed and built the first release end-to-end, beginning with three source-checked boxing-gym profiles in Playa del Carmen.
V1 constraints
V1 launched August 2026 · Product captured September 2026
Enlarge01 / Problem
A fighter landing in a new city has to answer a specific set of questions before committing to a gym — and the answers live in five different places, in different languages, at different levels of freshness.
Maps listing
Pin exists. Hours stale. No prices.
Social profile
Active, but info buried in posts.
Gym website
Sometimes exists. Rarely current.
Chat message
Answers, if someone replies.
Word of mouth
Trusted, but hard to find.
One structured profile
Olympus Boxing Gym ✓ Verified
Drop-in$50 MXN
TrainingBoxing
Beginner friendlyYes
HoursUnknown
ContactWhatsApp · Directions
Evidence before building
The product’s job is not merely to list businesses. It is to make the “Should I train here?” decision faster and more trustworthy.
02 / Product decision
The original idea was a marketplace matching fighters looking for sparring partners. That version introduced identity, safety, scheduling, trust and marketplace-liquidity problems before the basic discovery need had been validated. The first release deliberately solves the earlier problem in the journey.
Original concept
V1 decision
Gym discovery became the first wedge because it offered a direct path to utility while creating the dataset future features would need.
03 / Deliberate V1 scope
Each item was cut on purpose — parked, not forgotten.
Reducing scope made it possible to validate the information model and discovery workflow before building marketplace infrastructure.
04 / Data and trust
Real gym information is often partial, inconsistent or outdated. JabNGo avoids converting uncertainty into false confidence. Missing facts are shown as unknown or ask gym instead of being guessed.
On JabNGo, “verified” means the information was checked against available gym sources, with owner or coach input when available. It does not mean the gym has claimed or endorsed the profile.
Conceptual information model
Conceptual. This shows the information the product must represent, not a one-to-one map of database tables — the real schema is in Engineering.
The interface distinguishes between confirmed, unknown, “ask gym,” unavailable and potentially stale information:
Quick decision
Olympus Boxing Gym
✓ Recently source-checked
Drop-in$50 MXN
Monthly$600 MXN
HoursUnknown
ScheduleNot verified yet
05 / Product walkthrough
Step 1
The first release avoids a broad empty search experience by directing users toward the city with useful inventory.
EnlargeStep 2
Search and filters work together so users can narrow gyms by both identity and practical training requirements.
EnlargeStep 3
The empty state helps the user recover instead of presenting a dead end.
EnlargeStep 4
High-intent information appears before descriptive content and media.
EnlargeStep 5
Everything a fighter needs to commit sits above the descriptive content: what it costs, whether the hours are known, and two ways to reach the gym directly. Unknown hours are stated rather than hidden, and the contact buttons are the recovery path when the data is incomplete.
Enlarge06 / Engineering
Three decisions shaped the system: how gym facts are stored when most of them are partially known, how weekly opening hours become a single user-facing verdict, and how search and filters combine without overwriting each other.
Story 01
Gym facts change independently, so JabNGo does not treat a gym profile as one complete-or-incomplete record. Hours, pricing, classes, media, disciplines, amenities and contact channels are modeled separately. One category can remain unknown without preventing the rest of the profile from being useful.
Explicit states such as YES, NO and UNKNOWN, combined with last_verified_at, allow the interface to communicate uncertainty instead of replacing missing information with assumptions.
cities
gyms
gym_hours
gym_pricing_options
gym_classes
gym_social_accounts
gym_photos
gym_videos
gym_disciplines
disciplines
gym_amenities
amenities
Three schema decisions, read from the generated ERD
amount_minor is a nullable Intcurrency travels alongside it per row. Nullable is the point: a gym can have a named pricing option whose amount is not yet known.Stringopens_at, closes_at, starts_at and ends_at are strings, not DateTime. A weekly schedule is wall-clock time, not an instant: “opens 18:00 on Tuesdays” has no date attached, and storing it as a timestamp would force a fictional one.city_id. That pairing is what lets a weekly wall-clock schedule mean the same thing to a visitor reading the page from another country.Story 02
The city record stores the time zone needed to interpret recurring local schedules. The interface uses the available schedule information to present a user-facing opening state while preserving “hours unknown” when the source data is incomplete.
Because opens_at and closes_at are nullable and is_closed is explicit, the derivation has to distinguish “closed today” from “we do not know the hours” — and a gym with unknown hours must never satisfy an Open now filter.
Inputs
States
Story 03
The discovery interface combines the user’s search query and active filters to calculate the visible gym results. Search and filters can be applied simultaneously without erasing one another, which is what makes the result count read “1 of 3 gyms” rather than silently resetting.
Unknown values are treated as failing a filter rather than passing it, so an incomplete profile is never presented as though it met a requirement.
Descriptive city and gym routes create public, indexable pages that support discoverability today and city expansion later. Each new city is a new branch, not a new architecture.
/gyms/playa-del-carmen/gyms/playa-del-carmen/olympus-boxing-gym07 / What shipped
V1 makes the remaining product questions concrete and measurable. These are the open questions:
Instrumentation is planned, not yet collecting. These are the measures the first release was designed to make answerable — none of them have results yet.
Planned measurement, not collected results. No figures appear on this page because none exist yet.
08 / Lessons and next steps
1
Fighter matching was not the first problem in the user journey. Finding the right gym came before finding a sparring partner.
2
Trust is affected not only by whether information exists, but by whether users can tell what is current, missing or uncertain.
3
Launching one city with a complete decision path made the core discovery workflow testable without first building marketplace infrastructure.