This summary is private. Enter the password to continue.
TableMaster / Event Planning
Five ways to run The $250 DirtyStack, from using none of our software to running the whole event on it. What each one requires, and how confident we should be in it.
This page is kept as the record of the five options we weighed. The choice landed between B2 and C and took the shape neither quite described: One-Eyed Jack's keeps PokerAtlas as the system of record and the safety net, and our software runs registration, the clock, and the floor alongside it - kiosk check-in, live roster at the window, dealer tablets at every table, a director tablet, our clock on the room's own screens, and ten invited players on the app.
The plan for September 26 carries what was decided, what it commits us to, and what is still open. Read that first; this page explains how we got there.
We are not deciding how much software to finish. We are deciding how much of the night depends on it. Those are different questions, and the second one is about confidence rather than completeness.
Almost everything needed to run a tournament is already built. The clock, blind levels, registration, seating, and cross-device sync all shipped months ago. What none of it has done is run a real event, in a real room, with real players and real money. That gap is what this document is about.
The player app got materially more useful for the night. Push notifications are finished, and not only the manual kind. A message can now be composed and sent to players from the Admin app, and six automatic categories fire on their own. That was the last large build in front of a store submission, and it also changes what the app can do during an event in any option, since telling a player something no longer depends on them having the app open.
Nothing on the dealer or screen side moved, so the risk picture below is unchanged from four days ago. The calendar did move. The event is now 33 days away and the practical cut-off for anything we intend to rely on is about 12 days out.
It is the last full rehearsal before it. Anything we intend to rely on has to be finished early enough to run end to end in a real room at least twice, with time to fix what those runs expose.
That puts the practical cut-off in early September, not late. Thirty-three days to the event sounds workable; the honest figure is about twelve days of build before the rehearsals have to start.
Ordered by what breaks if it fails, rather than by how much software is involved. Each step up moves a failure from embarrassing to operationally damaging.
The room runs the tournament exactly as it does today, on its existing software. Ours is not operational on the night. The signup site is live and the app may be in players' hands, but nothing we built is responsible for anything.
If it fails: nothing to fail. No one in the room would notice.
We put a screen in the room showing things that do not change minute to minute: the schedule, the leaderboard, tour branding, promotion of the next stop. The room still runs the tournament its own way. We are decoration, and good decoration.
If it fails: a screen goes dark. Someone unplugs it. The tournament is unaffected.
The same screen, now showing a running tournament clock. This is a bigger step than it looks, and the reason is below.
If it fails: our screen shows the wrong level in front of the whole room. Worse than a dark screen.
RoomDirector is the source of truth for the night. Registration, the clock, seating, and results all live in our software. Dealers still work on paper. This is the first time the product does the job it was built for.
If it fails: you are recovering live, in front of paying players, with no fallback already running.
Everything in C, plus dealer tablets at the tables and the live clock in players' phones. Every surface we have built, doing its job at once.
If it fails: as C, across more surfaces, each able to fail on its own.
Our screen can only show a clock that our software is running. It cannot read the room's existing system. So a live clock on our screen means somebody is operating a second clock, by hand, all night, purely to feed the display.
That costs a dedicated person and introduces a very public failure: the moment they drift, our screen contradicts the real clock in front of everyone. B1 is nearly free. B2 buys a new way to look wrong. If we want a live clock on a screen, C is arguably the more honest place to be.
Required must work Optional choose per appetite - not used
| Capability | A | B1 | B2 | C | D |
|---|---|---|---|---|---|
| Before the night | |||||
| dsptour.com signup site | Req | Req | Req | Req | Req |
| In the room | |||||
| Screen showing schedule / leaderboard / branding | - | Req | Req | Opt | Opt |
| Live clock on the screen | - | - | Req | Opt | Req |
| Someone hand-driving a second clock | - | - | Req | - | - |
| Check-in / sign-in tablet for arrivals | - | Opt | Opt | Opt | Opt |
| Dealer tablets at the tables | - | - | - | - | Req |
| Running the tournament | |||||
| Registration taken in RoomDirector | - | - | - | Req | Req |
| Clock and blind levels run in RoomDirector | - | - | - | Req | Req |
| Seating and table moves in RoomDirector | - | - | - | Req | Req |
| Printed entry tickets | - | - | - | Opt | Opt |
| After the night | |||||
| Payouts settled in RoomDirector | - | - | - | Req | Req |
| Points awarded to the leaderboard | - | - | - | Opt | Opt |
| Player app (see separate section) | |||||
| Discovery, sessions and notes | Opt | Opt | Opt | Opt | Opt |
| Live clock in the player's pocket | - | - | - | Opt | Req |
Grouped by application. Effort is build time. Confidence is a different thing entirely, and the more important one: whether the thing has ever done its job for real. A short task with no track record is a bigger risk than a long task with a predictable outcome.
Proven has done this for real Untested built, never run live Known defect a specific fault to fix Unverified a suspected fault nobody has checked Not built
| Item | Needed for | Effort | Confidence |
|---|---|---|---|
| dsptour.com | |||
| Nothing outstanding. The parked design variant was dropped on 20 August, and the venue's written media permission is approved | All | Done | Proven |
| Display screen | |||
| Confirm it reads correctly on the actual TV in the room | B1, B2 | Hours | Untested |
| Run it for a full evening without dropping out | B1, B2 | Days | Untested |
| Check whether the screen carries the same sleep fault just fixed on the dealer tablet | B1, B2, C, D | Hours | Unverified |
| Windows packaging so it boots itself unattended | Not needed for one night with a person present | Weeks | Not built |
| A Windows code-signing certificate, which nobody currently owns. It gates both Windows builds, so neither can ship until someone buys it | Only if either Windows build is wanted | Days, plus purchase | Not built |
| RoomDirector | |||
| Room staff trained and comfortable running it | C, D | Days | Untested |
| Full dry run of an event start to finish | C, D | Days | Untested |
| A real settlement and payout, run once before the night | C, D | Days | Untested |
| Choose a scoring style so results award points | Only if points are awarded | Hours | Untested |
| Printed entry tickets at registration | Only if tickets are printed | Weeks | Not built |
| Dealer tablets | |||
| Tablet recovering by itself after a long sleep. Fixed and shipped; never yet watched across a full session | D | Built | Untested |
| A dealer pressing for the floor a second time inside five minutes reaches nobody | D | Hours | Known defect |
| Across everything | |||
| All five surfaces running together, watched for a full session | C, D | Days | Untested |
The previous edition of this document named one thing that would stop the full-stack option on the night: a dealer tablet stopped working when its session expired after about fifty minutes, and did not recover on its own. A tournament runs for hours.
That fix is now written, merged and live. A tablet left asleep now recovers by itself when it is woken. What has not happened is the part that would let us rely on it: nobody has yet watched a tablet run across a full session and come back from being asleep in a real room. Until that has been done once, this stays in the untested column rather than the proven one, but it is no longer a thing to build.
The same fix raised a fair question about the screen app, which shares the session code that was at fault. Nobody has read that code yet. Every screen we have reports a stale last-seen time, which fits the theory but fits equally with the screens simply being switched off. It is a few hours to check, and it matters from B1 upward rather than only in D, because a frozen clock on a wall is visible to the whole room and today nothing warns us it has happened.
It cuts across all five options rather than belonging to any of them. There are three decisions stacked inside it, and they are genuinely independent of each other.
This is the only choice with a long lead time attached.
None of these depends on which option we pick for the night.
The only part of the app tied to the option we choose.
Each of these changes what is required. The first two are worth settling before the rest are worth discussing.
A, B1, B2, C or D. Everything else follows from this.
Small trusted group, all participants, or public app stores. Only the third has a lead time that could miss the date, so it wants deciding early even though it is independent of the night itself.
This turns a first live event into the start of a season standing. It is a short task, but it has never run at the end of a real tournament, so it wants doing during a rehearsal rather than on the night. Since the last edition this has stopped being hypothetical: the same venue is running a two-week series right now and has asked us for a points race, which is a chance to settle the scoring style against a real field before September rather than during it.
The only way to print automatically at registration is a Windows desktop version, which is weeks of work. If tickets matter for September, this needs starting now. If they do not, it comes off the list entirely.
Attractive in every option, and the least explored. Worth a short conversation about what happens physically in the room today before we design anything: where a player goes, who takes the money, and what the person at the window needs to see.
First compiled 16 August 2026, updated 24 August from the live issue tracker and the current state of the code. Effort figures are build time only and deliberately coarse. Confidence is the judgement worth arguing with: it reflects whether something has done its job in a real room, not whether the code exists.
This page is deliberately not being kept current. It is the record of a decision that was taken on 25 August, and rewriting it would destroy what it is for. Only the event's name and the header were corrected on 3 September, because the event was renamed to The $250 DirtyStack after this was written. Everything else, including the day counts and the state of each surface, reads as it did on 24 August. For the current position see the plan, and for what remains to be built see the full-stack scope.
The physical-room assumptions in the check-in section are the least certain part of this document and should be corrected before they are relied on. Portfolio-wide status lives in the companion remaining work summary.