What 1.6 million bookings taught me about apps people actually use

Nova Sport, the sports platform I built and still run, has processed 1.6M+ bookings for 180,000+ users across half of Belgium's universities. At that scale, you can no longer tell yourself stories: the data shows what people actually do with an app, not what they say in meetings. These are the lessons that survived those years: the ones I now apply to every product I build for a client. None of them is spectacular. All of them are counter-intuitive for anyone who has never operated a product in the real world.

Speed beats features

Every time a new feature competed against a faster product, speed won. A booking done in three smooth taps gets used; the same booking through six slow screens gets abandoned, even when the slow version offers more options.

The reason is simple: a booking app lives in the gaps of the day. Between two lectures, on the tram platform. If the app does not respond instantly, the moment passes, and the intention with it. Features attract people on the store page; speed brings them back. A product that wants regulars should be judged on the time between opening the app and completing the action. Anything that stretches that time has to earn its place.

Onboarding is the product

Most users decide within their very first minutes whether they will come back. Not after a week of exploration, but in the first session.

I learned to treat the first-run experience as the product itself. Ask for the minimum information, show value before demanding effort, and get every newcomer to a first success (finding a partner, booking a court) as fast as possible. On Nova Sport, picking your sports and level in a few taps, then immediately seeing relevant partners and time slots: that sequence is what turns a curious visitor into a user.

The test I recommend to every founder: put your app in the hands of someone who has never seen it, explain nothing. Time how long it takes them to reach their first success. Every minute past two is a hole users fall through.

Notifications people don't mute

Notifications are the most powerful tool a mobile app has, and the most dangerous. Used badly, they are two taps away from being switched off entirely, and a user who muted your notifications is halfway gone.

The rule that held up: every notification must be about the user, personally, now. Your booking is confirmed. Your match starts in an hour. Someone joined your group. Zero "we haven't seen you in a while" messages. The distinction is easy to state: a service rendered to the user, not a service the app renders to itself. The second kind is paid for with the first kind's credibility.

The boring 20% that decides everything

Nobody starts a product because they dream of building password reset. Yet user trust is decided exactly there: accounts, payments, administration.

A cancelled sports session must refund or re-credit, immediately and visibly. A login must work on the first try, including after six months away. And the admin interface, the one the client uses daily to manage groups, slots and championships, deserves the same care as the public app. That is something the universities and companies using Nova Sport taught me: the back-office is your client's product, just as the app is their users'. The case study shows both sides.

In a budget, this boring part easily weighs a fifth of the total. Trimming it gets paid back in support tickets and lost trust, which is also why I always spell out what is included in my quotes.

Designing for a daily habit

An app that impresses in a demo and an app people use every week are two different objects. The demo rewards effect; the habit rewards consistency.

Designing for habit changes the priorities. Frequent actions must be reachable in one gesture from launch. The home screen must show what changed (new slots, new people, the next match) so that opening the app is always rewarded. And reliability outranks novelty: a habit is built on dozens of small successful interactions, and destroyed by two failures.

It is a shift of gaze: less "what dazzles on first contact", more "what is still useful the fiftieth time".

What I'd build differently today

Honesty requires it: knowing what I know now, some things would be done differently.

I would measure more, earlier. Early decisions were made on intuition; some were right, others cost months. A few well-chosen analytics events from day one would have accelerated every lesson in this article.

I would launch smaller. Features built in anticipation waited a long time for their users. Real demand is a better architect than forecasting.

And one thing would stay exactly the same: the care put into the main flow. That is what carried the growth, the partnerships with universities and companies, and the dedicated apps later built for five clients.

These lessons are now included in every product I deliver. If you are building an app you want people to still be using in three years, tell me about your project.