Back to Blog
By Shayne Case Study
Building CueTools: Connected Devices, Streaming and AI
The engineering behind CueTools: recovering match state, saving tournament setups, handling interrupted streams and validating AI-generated quizzes.
I founded CueTools in 2024 to build software for cue sports. The repository's first commits date to July that year. As the product developed, timing and scoring became connected to remote devices, saved settings, rules quizzes and native streaming.
The most instructive work was in the transitions: a phone reconnecting during a match, an organiser returning to a saved setup the next day, or a broadcaster changing their mind before going live. Those moments shaped both the architecture and the interface.
This case study draws on my development history, project discussions and recorded test sessions through November 2026. It focuses on specific engineering problems and what the work established.
A person controlling a shot clock needs a quick, predictable action. A display needs a clear view of the current match. A streaming device also has to manage camera, microphone, graphics and a connection to an external service.
CueTools shares web application code across parts of that experience, with native integrations for mobile capabilities. The build separates the browser experience from the native streaming bundle. The browser can serve the timer and scoreboard, including an OBS view, while the mobile build contains the camera and broadcasting features.
That separation makes release checks important: the browser bundle should not accidentally contain native streaming setup, and the native build should not lose it. A successful JavaScript build alone cannot establish that both products contain the right features.
One Remote Link problem appeared when several devices joined or rejoined the same match. More than one controller could respond to a request for current state, including a device holding stale defaults. Recovering a connection could therefore disturb information that was already correct.
The response needed a clear authority. The relay work selected an authorised source for recovery, prioritising the main device, rather than asking every peer to supply competing state. The client work also ensured a fresh connection could request current information instead of being blocked by a throttle from its previous connection.
A later local test exposed a different problem. With optional settings synchronisation disabled, a controller accepted live score changes but rejected scores in its reconnect response. The interface said it was linked, yet its match score was out of date.
The fix separated match recovery from preference synchronisation. A recently requested, valid match-state response could restore the score while preserving local names, appearance and timer preferences controlled by the settings switch.
The documented October 2026 lab session used a browser, an iOS simulator and an Android emulator. After closing the native apps, changing the host score and reopening them, the corrected implementation restored the host's score without another pairing step. That established a specific recovery behaviour in the lab; it was not a guarantee for every mobile network or physical device.
A useful question from development was whether someone running a multi-day tournament would need to configure and pair each table again every morning.
The settings-profile link identifies a setup stored in the same browser profile. Reopening it there can restore the saved configuration and pairing information. It is not a portable copy of that information for a different computer, and clearing browser data changes what can be recovered.
The interface needed to explain those boundaries. The resulting settings guidance tells an organiser to save the link, return in the same browser and close the earlier window before reopening that setup. A new window can intentionally represent a separate table, so treating every window as the same device would create a different problem.
This was a product-design lesson as much as a storage problem. Persistence only helps if the person operating the event understands what has been saved and how to return to it.
Streaming introduced several states that looked similar on a screen but meant different things: a configured destination, a running preview, an unused remote broadcast, an interrupted transmission and a completed broadcast.
One recovery investigation began with a saved broadcast whose provider credentials were no longer available. Repeated cleanup attempts left the app cycling back to an error. A confirmed local reset provided an escape, with an important distinction: forgetting local details does not prove that a broadcast has ended at the provider.
Another development discussion concerned the Edit Setup action. After preparing a stream, choosing to edit it should return to setup. A prompt that could reuse the existing broadcast and start streaming was a poor match for that intent.
The revised flow cleans up the unused broadcast before returning to setup, and retains the details for retry if cleanup fails. A recorded private YouTube setup test on Android checked that the unused broadcast, video and ingest stream were removed without starting the publisher. That test did not establish Facebook behaviour.
Native media work added its own constraints. The development history includes fixes to keep audio and video on a shared timeline, prevent duplicate frames and handle preview recovery after an Android sign-in interruption. These are reasons to test the lifecycle of the camera and microphone, as well as the controls drawn above them.
Rules quizzes offered a focused use for AI, but generation was only one step in the feature. Development uncovered repeated questions, invalid answer structures and the need to preserve recorded answers when repairing saved attempts.
The implementation added validation of option counts and answer indices, normalised question identities for duplicate filtering, and kept saved answers attached to the correct version of a question. Follow-up work handled exhausted offline questions, generation limits and retry feedback.
These checks improved how the feature handles data and failure. They do not establish factual correctness for every generated question. The relevant rulebook remains the reference for reviewing the content.
The broader lesson applies to business AI integrations: validate the output, decide what happens when the service is unavailable and make the limits understandable to the person using it.
The repository records regression tests around reconnection, missed scores, stored settings and quiz behaviour, alongside release checks for the web and native builds. The local device lab used isolated fixtures so that tests could exercise real transport behaviour without changing production accounts.
Different checks answer different questions. A simulator can reproduce a state-recovery bug. A local media receiver can inspect encoded frames. A physical phone can expose capture or lifecycle behaviour that a browser test misses. A short test cannot establish battery life or reliability throughout a long event.
Keeping those limits explicit made the evidence more useful. It gave the next test a purpose and reduced the chance of treating a green build as proof that every live workflow was covered.
You can explore the product at cuetools.app. If you are building an application with connected devices, complex workflows or AI features, I offer custom software development and AI integration from Brisbane. Tell me what you are working on.