How to build a football scores app with a world-class experience
A score that arrives seconds late loses its value. How I design a live-scores system that holds when everyone opens the app at once, from my work on 90Plus.
In short
- In a live-scores app speed is the product itself, and news that arrives seconds late has lost its value.
- Load does not arrive evenly: you know when the match is, but not when the goal will come, so the system is designed for that moment.
- The notification is the hardest part: it must arrive fast, arrive once, and be quietly corrected if the goal is disallowed.
In this article
In football, news that arrives a few seconds late is no longer news. The fan waiting for the goal notification hears the neighbour shout before the phone vibrates, and quietly decides that this app cannot be relied on. That is the problem I keep coming back to in scores apps, 90Plus among them: the goal and its notification should arrive before the replay, even at the peak of a big match.
A product made entirely of speed
90Plus is a live-scores app for iOS, Android and the web. I worked on it as part of my work with Dudes Studio, and covered most of it: the data merging, the realtime and notification system, and the app’s design and performance. It does not simply read its own database and show what is there. Match events reach it from three data providers. Services written in Go receive them and push them live to the app and to phones as notifications, and on iOS a live activity sits on the lock screen. In our comparisons, its goal alerts arrived before those of well-known apps such as 365Scores and Yalla Shoot.
Live scores and mobile app90PlusA live scores app that merges data from three providers into one accurate source, with goal alerts that arrive before the best-known score apps.
The audience is Arabic-speaking, so Arabic names and news are part of the design, not a layer stuck on top of a foreign product. The site and the app serve different purposes. The site answers someone looking for a score right now. The app keeps the fan close to you, and the notification is the thread that connects you.
In most products you can fix slowness later. Not here, because slowness is the first thing the user notices and the last thing they forgive. Nobody praises a scores app for being fast, but everyone leaves one that was late once in front of the neighbours.
Speed is a chain, and the slowest link sets it
Between the stadium and your phone there are several links: the data source, your reading of it, the preparation of the news, and its arrival on the device. You can never be faster than the slowest of them. Before you promise anyone speed, find out how long each link takes and which ones are out of your hands.
Data sources differ in speed and in price, and the faster ones usually cost more. That makes the choice of source a financial decision before it is a technical one. Most apps rely on a single provider at best. In 90Plus the data came from three.
Three providers, one match
Each provider spells team and player names its own way, sends events on its own timing, and sometimes gets something wrong and corrects it later. If you show whatever arrives as it is, the fan sees the match twice, the goal twice, or a line-up that does not match the pitch.
So we built a layer that matches fixtures, teams and players across the three providers, decides which event to trust and which is a duplicate, and stops conflicts before they reach the screen. It uses matching algorithms, with AI for the cases that fixed rules cannot settle. The fan sees one match, and one correct version of each event.
Load does not arrive evenly
An ordinary app gets its visitors throughout the day. A scores app gets them in waves: before kick-off, at every goal, and at the final whistle. And they all ask for the same thing in the same second.
| Item | Ordinary app | Live-scores app |
|---|---|---|
| Shape of the load | Spread over the day | Sharp waves around certain moments |
| Effect of slowness | An annoyance people put up with | Reason enough to leave the app |
| Notifications | An extra feature | The heart of the product |
| Errors | Fixed later | Seen by everyone straight away |
The time of a match is known. The moment of a goal is not. Design the system for that moment, not for the schedule.
Do not let viewers ask the source
The rule I build on is that no viewer ever asks the data source directly. A few services read the source and prepare the result as a ready copy, and everyone reads from that copy. That way the load on the source does not grow as the number of viewers grows.
Think of a restaurant at its busiest hour. The kitchen does not start every dish from nothing for every order. The base is prepared before the customers sit down, and the ready copy is that base.
I recommend Go for this kind of work in particular. It is the language of the services that receive live events and broadcast them in 90Plus, because reading continuously and broadcasting to many connected users at once is exactly what it was designed for.
- Live data source
- Reading services
- Ready copy for everyone
- App and website
- Phone notification
The notification is the hardest part
The notification is the peak within the peak. Everyone who follows the team needs it at the same moment. Part of its journey runs through Google’s and Apple’s networks, so not all of it is in your hands, which is one more reason to speed up the part you do own. And apart from the congestion, notifications have problems that never show up in a demo.
Too many notifications
A fan who gets a notification for every match in the world turns all notifications off. I prefer to let the fan choose what to follow, whether teams, tournaments or players, and to send them only what matters to them.
The goal that gets disallowed
A goal can be scored and then disallowed after a referee’s review. The source corrects its news, and your system has to correct what it sent, quietly, so the fan is not left celebrating a goal that does not exist.
The duplicate notification
The same news can arrive from more than one source, or be sent twice because of a small fault. A fan who gets the same notification twice concludes that the app is confused. The system has to know that it sent this event a moment ago.
Names in Arabic
People write a player’s name in several different ways. If the notification spells it one way and the page another, the app looks careless. I count consistency here as part of quality, however small it looks.
Warning: A wrong notification costs more than a late one
A notification that is seconds late costs you a moment. A wrong or duplicated one costs you the fan’s trust. If you have to choose, choose accuracy.
When things go wrong
You know a good system by what it does when things go wrong, not by how it runs when everything follows the plan. There are three situations I think through before any big match.
When the source drops
One day the source will fail in the middle of a match. The question is what your app shows when it does. The worst choice is to show the old score as if it were live. The better one is to say honestly when it was last updated. A fan will accept a fault you admit to, but not an old score passed off as a current one.
Who stays up with the match
On the night of a big match, a well-designed system is not enough. Someone has to be watching it. A single screen showing the delay between event and display, the number of connected users and the notification errors is enough to tell you that something is getting worse before the fans write to you. A message for users, prepared in advance for when a fault happens, saves you precious minutes.
The mid-range phone is the yardstick
Most of your users do not have the newest phone or the fastest network, which is why I measure every product of mine on a mid-range Android phone. In Madar, for example, I set a target that the store page should appear in under two seconds on such a phone over 4G. The same principle applies to the scores screen: a light page that opens at once is better than a beautiful one that arrives late.
What this means for whoever puts up the money
The day of the big match is also the day new visitors arrive. People search for an app and download it that same day. If the app goes down then, you have lost the biggest marketing opportunity of the year and gained nothing for it.
The system therefore has to be sized for the worst moment rather than the average day, and tested under artificial load before the tournament, never during it.
Speed has a cost: faster sources, and servers that can take the peak. The question an investor should ask is how much it costs to lose a fan at the first big match they follow, more than how much the speed itself costs.
Questions for whoever promises you a live-scores system
The short version
Build for the worst moment, not for the ordinary day. In match scores, speed is the product itself and cannot be added at the end as a feature. Every design decision is measured against one question: does the goal arrive before the replay?
Projects mentioned in this article
Questions
Why are some score apps seconds behind others?
Because each app reads from a source and passes the news through layers, and every extra layer adds delay. The difference shows most at match-day peaks.
Is it enough to buy a ready-made scores service?
It gives you the data, but it does not give the user speed, the notification or the correction. Those remain the responsibility of your own system.
What is the worst time for an app to go down?
During a big match, because that is when the most new visitors arrive, and you only get one first impression.
