SnookerIQ: How a simple idea took over my world

I've played snooker for years, and during that time I've accumulated a considerable amount of information about my performances. Matches played, frames won and lost, breaks made and various other statistics which, collectively, provided a fairly comprehensive record of my ability to knock coloured balls around a table. Unfortunately, while the data was plentiful, my ability to make any meaningful sense of it was rather less impressive.

I wanted to understand whether I was improving, identify patterns in my performances and see where my strengths and weaknesses lay. It also occurred to me that a few attractive charts might make the occasional disappointing result feel marginally more scientific. Rather than simply acknowledging that I'd played badly, I could at least establish precisely how badly, and perhaps identify a statistical trend suggesting that things were getting better.

So I decided to build an application that would take my historical data and turn it into something useful. There would be a dashboard, some charts, a few performance indicators and perhaps some clever calculations to measure aspects of my game that weren't immediately obvious from the scores alone. It was intended to be a relatively straightforward personal project, a way of satisfying my curiosity while developing something that might actually be useful.

That was before I started having other ideas.

From historical analysis to live scoring

The first complication arose when I realised that an application designed to analyse years of historical snooker results would become increasingly pointless unless I continued feeding it new information. I could, of course, keep recording matches elsewhere and importing the results afterwards, but having built an application to make life easier, that seemed an unnecessarily cumbersome arrangement.

What if I could record the results directly in the application? Better still, what if it had a scoreboard that could be used during a match, automatically capturing the information required for the analytics? That would remove the need for separate record-keeping and allow the statistics to update as soon as a match finished.

It seemed a perfectly sensible extension of the original idea. I already had a system for displaying information, so adding another screen to record it didn't strike me as a particularly dramatic development. The scoreboard would handle scores, fouls and breaks, store the results and feed the numbers into the existing analysis.

Naturally, it turned out to be rather more involved than that. Snooker has a surprising number of rules and situations to consider when you're attempting to translate what happens on a table into software, particularly if you want the resulting statistics to tell you something useful. Recording a score is straightforward enough, but recording the events that produced it, and doing so without interfering with the flow of a match, introduces a different level of complexity.

Nevertheless, the scoreboard took shape, and with it came the realisation that what I'd created might be useful to people other than me. If I wanted to understand my performances, surely other players might want to do the same? There were already ways to record scores, but I was interested in going beyond the result to examine the quality of a player's game, the consistency of their performances and the aspects of their snooker that were improving or deteriorating.

The original analysis tool gradually became a live scoring and performance platform, with more sophisticated statistics, player comparisons and measures of ability. I developed concepts such as MySnookerIQ and the Break Quality Index, intended to provide a broader picture of performance than simply counting frames won or recording the highest break.

By this stage, the project had acquired a name, SnookerIQ, and the original plan to visualise some old snooker results had been quietly abandoned in favour of something considerably more ambitious.

An app is apparently not just an app

One of the things I've discovered through building SnookerIQ is that the application people interact with represents only a fraction of the technology required to make it work. From a user's perspective, it's a scoreboard and a collection of analytical tools. You open it, record a match and examine the results, perhaps discovering that your recollection of a particularly impressive performance doesn't entirely survive contact with the statistics.

Behind that relatively simple experience sits an assortment of systems, each responsible for a different part of the operation. None of them is especially mysterious in isolation, but together they form a technological ecosystem that bears very little resemblance to the modest project I originally imagined.

The first requirement was somewhere to keep the code. A code repository provides a central home for the files that make up the application, maintains a history of changes and allows development to proceed without losing track of what has been altered. It's also rather useful when a supposedly minor improvement unexpectedly breaks something that was working perfectly well ten minutes earlier.

Then there's the database, which stores the information generated by players and their matches. This has become substantially more involved than a collection of rows containing scores and dates. Player accounts, individual frames, statistics, performance histories and relationships between different pieces of information all need to be managed, while ensuring that one person's data doesn't accidentally become available to somebody else. There are security policies, access permissions, database functions and processes designed to keep everything consistent as the application evolves.

Having created the code and somewhere to store the information, I needed a way to make the application accessible over the internet. That introduced a hosting and deployment platform, responsible for turning the code into a functioning website and publishing new versions whenever changes are made. Ideally, this happens automatically, although I have learned that the word 'automatically' in software development often means 'automatically, provided seventeen other things are configured correctly'.

I also needed a domain name, because asking people to visit a lengthy and largely meaningless technical address didn't seem like the best way to establish a recognisable product. That meant registering the name and configuring the DNS records that tell the internet where the website and application can be found.

DNS is one of those essential technologies that most people use constantly without ever needing to know it exists. It's effectively the internet's address book, translating familiar website names into the technical addresses computers use to communicate. It also has the entertaining characteristic of occasionally taking its time to recognise changes, leaving you wondering why everything works on one device while another remains convinced your website lives somewhere else.

At this point, I already had a code repository, database, hosting service, domain registrar and DNS provider, all supporting an application whose original purpose was to show me whether my snooker was improving.

And I was nowhere near finished.

The supporting cast expands

Once SnookerIQ became something other people could use, another set of requirements appeared. Players needed individual accounts, which meant providing a secure way to register, sign in and recover access if they forgot their password. An authentication service handles much of this, but it still has to be connected to the application, configured correctly and integrated with the database so that everybody sees the information they're entitled to see.

Account registration and password recovery also introduce email, which turns out to be another specialist service entirely. Rather than operating an email server myself, which would be an ambition bordering on self-harm, I connected a platform designed to deliver transactional messages reliably. That brought its own configuration requirements, including domain verification, sender authentication and various technical records intended to reassure receiving mail servers that the messages are genuine.

Then I introduced IQ+, a subscription providing access to additional analytics and features. The decision to offer a paid tier wasn't simply a matter of adding a price and hoping somebody would hand over their credit card details. Taking payments properly requires a dedicated payment platform, capable of managing recurring subscriptions, renewals, cancellations and the various things that can happen when a payment fails.

The payment system has to communicate with SnookerIQ so that the application knows which users have an active subscription and which features should be available to them. This involves another collection of technical connections, permissions and automated notifications, ensuring that a payment made in one system produces the correct result in another. Fortunately, the financial transactions themselves are handled by specialists, rather than by some code I've written after watching a couple of tutorials and deciding that banking probably isn't as complicated as people make out.

Alongside the application, I created a separate website to provide information about SnookerIQ, publish articles and explain what the various features do. Rather than editing the website's code every time I wanted to update an article, I added a content management system, which provides a publishing interface and stores the material independently of the website itself.

There are also services to monitor usage, track errors, manage files, perform scheduled tasks and help me understand whether the platform is behaving as intended. Security certificates protect connections, automated processes carry out work behind the scenes, and an assortment of configuration settings and access credentials allows the different components to communicate.

Every addition has a rational explanation. Each service solves a particular problem, usually more reliably than I could solve it by building the equivalent technology myself. The difficulty is that every solution also introduces another relationship to manage, another collection of settings to understand and another potential source of problems when something stops working.

It has become the technological equivalent of buying a small garden shed and gradually discovering that you've built an industrial estate around it.

The invisible complexity of modern software

The interesting thing about SnookerIQ is that it isn't a single enormous piece of software responsible for everything. It's a collection of specialist services that cooperate to deliver what appears, to the user, to be one application.

The scoreboard operates in the browser, the database preserves the results, the authentication service confirms identities and the payment platform looks after subscriptions. Another service sends emails, another publishes the application, and the content management system delivers articles to the website. Most of these services communicate through APIs, which provide agreed methods of requesting information or triggering particular actions.

When somebody subscribes to IQ+, for example, the payment service processes the transaction and communicates the result back to SnookerIQ, which can then update the user's access to the additional features. When somebody requests a password reset, the authentication system and email service work together to deliver the necessary message. When I publish an article, the website retrieves it from the content management system and displays it without requiring the application itself to be rebuilt.

This is an extraordinarily powerful way of developing software because it allows a relatively small project to use infrastructure that would once have been available only to organisations with substantial technical resources. I don't need to write a payment processor, build a database engine or operate a network of email servers. Instead, I can use established platforms designed specifically for those purposes and concentrate on the things that make SnookerIQ different.

The disadvantage is that I'm now responsible for ensuring those systems continue to cooperate, and diagnosing problems across several independent services can become an interesting exercise in detective work. Something that appears to be wrong with the application might actually originate in a database query, an authentication setting, an expired credential or a communication failure between two systems that were perfectly happy with each other yesterday.

The growing sophistication of the platform has also created a rather different set of responsibilities from those I anticipated when I first started. I now have to think about the security and privacy of other people's information, how long data should be retained, what happens when an account is deleted and how to ensure subscription access remains correct when circumstances change.

And because practically every cloud service has some form of usage allowance, there's also the question of capacity and cost. Many platforms offer generous free tiers, which make it possible to get started without considerable expense, but databases have storage limits, hosting services have allowances and email systems place restrictions on the number of messages they will deliver. As SnookerIQ develops, I have to understand those limitations and decide when additional capacity becomes necessary.

This is quite a departure from wanting to produce a graph showing my potting percentage.

The remarkable thing is that I could build it

For all the additional complexity, the most extraordinary aspect of this experience is that creating something like SnookerIQ is now within the reach of an individual working on a personal project.

A relatively short time ago, an application involving live scoring, detailed performance analytics, user accounts, cloud databases, subscription payments and multiple integrated services would have represented a substantial undertaking. It would have required specialist development skills, expensive infrastructure and probably several people with different areas of expertise.

Today, cloud platforms provide much of the infrastructure as a service, while modern development tools make it considerably easier to connect everything together. Artificial intelligence has also changed what is possible, particularly for somebody like me who is perfectly comfortable coming up with ideas but doesn't necessarily possess years of professional experience in every technology required to implement them.

AI has helped me develop features, understand unfamiliar systems, investigate errors and turn ideas into working software. It can explain why a database operation is failing, suggest more efficient ways to structure code or help work through a technical problem that might otherwise involve several hours of searching documentation and experimenting.

That doesn't mean I can simply describe an application, press a button and return later to find a finished product. Someone still needs to decide what it should do, how it should behave and whether the resulting features are any good. In SnookerIQ's case, much of that comes from understanding snooker itself, knowing which statistics are meaningful and considering how somebody might actually use the application while playing a match.

There are also plenty of occasions when the technology confidently produces something that is wrong, or fixes one problem while introducing another. This requires testing, questioning and occasionally explaining to an AI assistant that its latest ingenious solution has managed to make the situation considerably worse.

What these tools have done, however, is reduce the distance between having an idea and being able to do something about it. I've always been inclined to look at something that doesn't exist, wonder why nobody has created it and then consider whether I might be able to build it myself. The difference now is that the practical barriers to doing so are considerably lower.

Of course, removing those barriers also removes some of the natural restraints that might previously have prevented a fairly simple project from expanding into an entire technology platform.

There is probably a lesson in there somewhere, although I suspect I'm unlikely to learn it.

From a spreadsheet to a platform

Looking back, I can trace almost every element of SnookerIQ to a perfectly reasonable decision made along the way. I wanted to analyse historical performances, so I developed a way to visualise the data. I wanted to keep that information current, so I added live scoring. Recording matches required persistent storage, which led to the database, while making the application available to other people introduced user accounts, authentication and the necessary security measures.

As the analytics became more sophisticated, I developed additional features and a subscription model, which required a payment platform. The need to explain the product and publish information led to a separate website and content management system, while making the whole thing accessible introduced hosting, domains, DNS and the other components that most people never see.

What started as a way to understand my own snooker performances has become a functioning platform supported by a network of interconnected services, each performing a small but important part of the operation. From the outside, it's an app; from my perspective, it's a constantly evolving collection of software, databases, infrastructure, integrations and ideas that occasionally requires rather more attention than I originally intended.

I don't regret any of it, because the experience has been fascinating and I've learned an enormous amount about technologies that I would otherwise have had little reason to explore. There's also considerable satisfaction in seeing something that began as a personal curiosity become a product that other people can use, particularly when the features reflect ideas I originally developed to answer questions about my own game.

And inevitably, there are still things I'd like to add. Better analysis, more useful comparisons, new ways of interpreting performance and improvements to the experience of recording a match. Every time I think I've reached a reasonably complete version of SnookerIQ, another possibility occurs to me, usually followed by the familiar thought that it shouldn't be too difficult to implement.

Which is, of course, exactly how this whole thing started.

Somewhere beneath the code repository, database, authentication service, payment processor, email platform, publishing system, hosting infrastructure, domain registration and DNS configuration is the original question that prompted me to build SnookerIQ in the first place: after years of playing snooker, was I actually getting any better?

The application has certainly improved. The evidence concerning its creator remains somewhat less conclusive.

You can explore SnookerIQ at snookeriq.co.uk (opens in a new tab), or try the app at app.snookeriq.co.uk (opens in a new tab). It won't necessarily make you a better snooker player, but it should provide a much more sophisticated explanation of why you're not one.