MojoDojo

The problem

Martial-arts academies are almost always run on tools that were never built for them: a spreadsheet for the student roster, a notebook for payments, loose messaging for announcements, and the instructor’s memory for everything else. It works until it doesn’t. As a gym grows, every uncollected monthly fee, every unrecorded belt, and every un-logged attendance turns into manual work that steals time from the mat.

Generic gym-management software doesn’t fit either: it ignores what makes martial arts specific —grades and belts, technical progression, discipline-based tracking— and forces you to bend your process to fit a “fitness” mold.

The role — solo founder

I built MojoDojo entirely on my own, end to end: product, architecture, backend, frontend, database, billing, and deployment. It’s a solo project (sole founder, not co-founded), which meant scoping it with the same discipline you’d apply to the code: focus on what a real gym uses every day, and leave everything else out.

The process

• Start from a real gym. The product didn’t come from a market hypothesis; it came from the daily operations of one specific academy. That set the priorities: first the things touched every week —students, attendance, payments—, then the nice-to-haves.
• Iterate with the user inside the loop. Because the gym was in production early, every feature was validated against real use rather than a mockup.
• Pick a boring, solid stack. Go for a predictable backend, React for an interface that non-technical instructors use without friction, PostgreSQL as the source of truth, and Stripe so I never reinvent payments or hold sensitive card data.
• Disciplined scope. As a solo project, every feature had to earn its place. The rule: if the gym doesn’t need it this week, it doesn’t ship yet.

The solution

MojoDojo is a management SaaS for martial-arts academies that brings into one place what used to be scattered across spreadsheets, notebooks, and messages:

• Student management and records.
• Attendance tracking and grade/belt progression.
• Recurring membership billing via Stripe.
• An interface built for gym staff to use, not a systems administrator.

The design goal was for the tool to disappear: less time in front of a screen, more time on the mat.

Outcomes

• In production at a real gym, with ~300 users. Not a demo, not a pilot: it’s the tool an academy runs its day-to-day on.
• Replaces the spreadsheet-and-manual-payments workaround with a single system.

Learnings

• One real user beats ten interviews. Having a gym in production from the start turned every decision into a testable hypothesis.
• Scope is the hardest function a solo founder ships. With no team, saying “no” on time is what keeps the project alive and maintainable.
• “Boring” is a virtue in infrastructure. Go + PostgreSQL + Stripe mean fewer 3 a.m. surprises.
• Specializing beats generalizing. Speaking the language of martial arts —belts, grades, disciplines— is exactly what generic gym software doesn’t do.