Our approach

Your Gym Has No Signal. Your Software Should Not Care.

Half the rooms this sport happens in are basements, metal sheds, and back corners of industrial units. Almost all sports software is built as though that is not true.

Share
Illustration of a phone working with a crossed-out cloud above it

The wrestling room at my old high school was in a basement with cinderblock walls. The best jiu-jitsu gym within an hour of me is in a metal building on an industrial estate. I have been to fight cards in arenas where you could not send a text from the floor. Every one of those is a place where sport actually happens, and every one of them is a place where a phone shows one bar or none.

So when a training app throws up a spinner because it cannot reach a server, it is not failing in an edge case. It is failing in the room it was built for.

Why almost everything is built online-only

Not laziness. It is genuinely, substantially easier. If every read and write goes to a server, there is one copy of the truth, no conflicts to resolve, no local database to migrate when the app updates, and nothing to reconcile when a device has been offline for two weeks. Building the offline version is more work in almost every part of the system.

The reason it gets skipped is simpler than architecture, though. The people making the decision are testing on office wifi. The problem is invisible from where they are standing.

What offline-first actually means

The phrase gets used loosely, so here is the distinction that matters.

Online with caching means the app talks to a server, and keeps a copy of some things so it can show you a screen when the network drops. You can usually look at things. You often cannot reliably do things, and what you did while offline may or may not survive.

Offline-first means the app reads and writes to a database on your device. That is the real copy, not a cache. Your action is complete the moment you tap save, whether or not there is any network at all. Sync is a background process that reconciles your device with the server later, and it is an optimization, not a requirement.

The test is not "does it show me something without signal". It is "if I log an entire session in a basement with airplane mode on, and my phone dies on the drive home, is my session still there tomorrow". Offline-first answers yes.

The four moments where this decides everything

Logging between sets. You have forty-five seconds. If the app hesitates, you put the phone down and tell yourself you will do it later, and later is a worse, shorter, half-invented version of the truth.

The door at 6pm. Thirty people arriving in ten minutes and the gym's connection drops. Either check-in keeps working on the tablet or the front desk goes back to a paper list and you lose the attendance data for the busiest class of the week.

A tournament in a metal building. A coach with eight athletes across four mats, no signal, needs the schedule, the bracket notes, the medical information, and the ability to write down what just happened. This is the highest-stakes, lowest-connectivity environment in the sport.

Fight day. A fighter in a back hallway who needs to show their paperwork. That is not a moment for a loading spinner.

The real cost is not inconvenience

Here is the part that took me a while to understand properly. An app that is unreliable in the gym does not produce mildly annoyed users. It produces people who stop logging.

And a training log with holes in it is worth much less than half a complete one, because the entire value of a log is trend and pattern. If three weeks of March are missing because the wifi was bad, you cannot answer whether your volume was climbing before the injury. The gap does not just lose those sessions. It undermines your confidence in every conclusion the log might have offered.

The same is true on the gym side. Attendance data with a hole in it cannot answer "who has quietly stopped coming", which is the single most valuable question a gym can ask its own records.

How we built it, plainly

Every iVenza mobile app carries a full local database. When you log a set, weigh in, or check a member in, that write lands on the device and is complete immediately. Nothing is pending, nothing is queued in a way that can be lost, and there is no spinner.

Sync runs in the background when a connection exists. It sends up what changed and pulls down what changed elsewhere. If you have been offline for a week, it catches up when you land.

When two devices have both changed the same thing, we needed a rule, and the honest thing is to say what it is: the change that is pushed most recently wins for that record, and a change you have made on your device that has not yet been sent always beats an older copy arriving from the server. In practice this is almost never visible, because two people rarely edit the same record. When it does matter - a coach and an athlete both editing the same session - the rule is at least predictable, which is more than "whatever happened" offers.

The limits, stated

Being straight about this is part of the point.

  • The web app is not offline-first. It runs in a browser and needs a connection. It is the fastest way to start, it works on any machine, and it is genuinely good - but the offline promise is a mobile app promise, and we are not going to blur that.
  • Some things genuinely need the network. Taking a payment. Discovering gyms or events you have never loaded. The features that send a photo of a whiteboard off to be turned into a workout. Anything involving another person in real time. We would rather say so than pretend.
  • Media uploads finish later. Video and photos are recorded and attached immediately, and the bytes upload when there is a connection worth using.
  • A device is not a backup. Local-first means the data is on your device; sync is what means it also exists somewhere else. Both halves matter.

This is also a position about ownership

There is a connection between offline-first and something we have written about before. If the app genuinely works with the server unreachable, then your training history is on a device you own, in a form the app can read without permission from anyone. Export is not a favor we do you, it is a copy of something already in your hands.

Software that cannot function without its server has, whether or not it intends to, made your record conditional on a company continuing to exist and continuing to like you. We would rather build the version where the basement works.

FAQ

Does iVenza work without an internet connection?
The iPhone and Android apps do. They keep a full database on the device, so logging a session, checking a member in, weighing in, or writing a note completes instantly whether or not there is any signal, and syncs when a connection returns. The web app runs in a browser and needs a connection.
What syncs, and when?
Everything you record syncs in the background whenever a connection is available, sending your changes up and pulling other people's down. If a device has been offline for a week it catches up when it reconnects. Photos and video attach to the entry immediately and upload the underlying files when there is a usable connection.
What happens if I log on two devices at once?
For any single record, the most recently pushed change wins, and a change made on your device that has not yet been sent always takes precedence over an older copy arriving from the server, so unsynced local edits are never silently overwritten. In practice conflicts are rare, because two people seldom edit the same record at the same moment.
Why does offline support matter for gym software specifically?
Because of where sport happens. Basements, metal buildings, industrial units, and arenas are all places with poor connectivity, and they are exactly where training and check-in occur. An app that hesitates in those rooms does not produce mild inconvenience, it produces people who stop logging, and a training or attendance record with gaps in it cannot answer the questions it exists to answer.

How this works in iVenza: Data, backup & sync →