Gym Management Made Simple

MatNative makes life easier by automating the tedious tasks that take you away from the mats.

No surprise fees

Always know the exact fees coming from memberships, and how much goes into your bank account.

⚠️ Disclaimer

This project is a current, ongoing project that I intend to sell as a B2B SaaS product. As such, its description and appearance will change over time!

Business Case

Managing a Jiu Jitsu gym is, in many ways a paradox. On the one hand, it’s one of the most rewarding jobs you can have——to see people come and develop themselves, not only physically but especially mentally and emotionally. However, Jiu Jitsu can also be a thankless job. You break your body for decades to acquire the skills and talent necessary to train others. To say nothing of the precarious juggling that maintains the gym’s health: cleaning, maintenance, bookings, marketing, lead-follow-ups, and so on. The amount of behind-the-scenes work is immense and unfortunately it usually ends up cutting into the first love that brought the gym to life in the first place: training Jiu Jitsu.

MatNative’s reason for existing is to bring those owners back to the mats. To rescue their time from the tyranny of the urgent and the time-consuming. MatNative’s goal is to make running a gym effortless; to reduce the friction between all of the administrative work needed to keep things running smoothly.

⚙️ Technical Case Study

If you care about the technology that went (and is still going) into building MatNative, read on!

The Technical Values

MatNative has a few technical requirements in order to make it successful.

1. It needs to be dead simple. Part of the problem with existing solutions, are that they aren’t built for jiu jitsu gyms. They’re built for gyms in general, and as such, they’re bloated with features that are irrelevant to jiu jitsu gyms. If we’re going to win at the task of getting gym owners back on the mats, we need to help them spend as little time as possible in MatNative.
2. It needs to have a ridiculously fast iteration cycle. I should be able to take an idea from a gym owner, and immediately begin iterating on it in a way that’s not intrusive to existing users, but allows ideas to be tested and validated.
3. It needs to be work the first time, every time. Gym owners are busy people. They don’t have time to deal with bugs and issues. If MatNative is going to be successful, it needs to be rock solid. This includes a robust testing philosophy, and a commitment to quality.

Behind these 3 core requirements lie (most) of the justifications for the technological decisions I’ve made.

To address simplicity and iteration speed, I’ve chosen to use tools that I’m very familiar with. Having used Typescript, React, and NodeJS for years, I’m well-versed in most of the pitfalls and surrounding tooling that will be used to make a solid business product.

To address quality and reliability, I’m ensuring full-stack type-safety using Typescript + graphql-codegen. A breaking change on the API, will immediately throw red all over the client where I’ve broken existing contracts. Because I’m a solo developer building in a monorepo, this allows me to confidently make “breaking changes” knowing that I’m actually not breaking anything at all.

The Architecture

MatNative’s architecture has shifted a bit as I’ve narrowed down the things that really matter and the “nice-to-haves”. Originally, I was using Ionic Appflow along with the core Ionic Component Library to build the app. I wanted a native app experience, and I didn’t want to deal with the hassle of building a native app, which directly flew against values #1 & #2——I’m not a mobile app developer, and I didn’t want to spend a ton of time learning how to build a native app.

Eventually, it became clear this was adding a ton of friction without a ton of upside. Things like:

• App Store approval times / App Store review process
• Debugging a webkit view within a native app
• Separate iOS / Android build processes within Capacitor

Ended up yielding a ton of additional technical overhead that didn’t feel like it yielded much benefit.

The stack is now a responsive progressive web app, which currently works for the other technical restraints we’re working under which include being able to use the device’s camera, and geolocation (and maybe soon push notifications!).

The front-end architecture is built with React, Firebase Auth, Apollo Client, and Ionic Components.

The back-end architecture is built with NodeJS, Express, Apollo Server, Prisma, Supabase, and Postgres.

The hosting is done by Heroku and Netlify.