The verdict: we are not behind, we are aimed somewhere else
TableCaptain is a cash-room floor desk, built for a floor person standing at a terminal moving people between live games all night. It is mature at that job and it carries a cage.
RoomDirector is a tournament and player-engagement platform that also runs a cash floor. We are meaningfully ahead on tournaments, player loyalty, content and self-service, and we are a web app against their installed desktop client.
The honest gaps are narrow and mostly cheap. Must-move is the one that would embarrass us in a demo to a busy multi-table room, and it is completely absent from our codebase.
We lead11Whole capability areas they either lack or never demonstrated.
They lead9Verified absent from our code, not just unseen.
At parity8Both do it. Differences are execution, not existence.
Where we lead
Marketing ammunition
Each of these is present in our code and either absent from their menus or present as a menu item their videos never opened. Where it is the latter, it says so.
Tournaments, end to end
Our strongest lead
Schedule, creation wizard, structure and blind levels, clock with start / pause / resume, initial seating generation, rebalancing and reassignment with floor-assistant recommendations, results and payouts.
RoomDirectorEleven tournament routes plus a dedicated seating engine and a tournament workspace with a floor panel.
TableCaptainA Tournament menu item and a Tournament Director role. Never opened on camera, so depth is unknown.
Say it carefully. They have something here. We simply cannot see how much, so claim our depth rather than their absence.
Player loyalty loop
Verified gap
Points, per-room leaderboards, per-period player stats, and player profiles with tournament and cash history.
RoomDirectorLeaderboard and scoring config are first-class screens. Points appear across 27 files.
TableCaptainA patron Tier field on the player panel. No leaderboard, no points, nothing earning the tier.
High hands as a workflow
Verified gap
Recorded, with card capture and a decision state machine: Undecided, Waiting on a decision, Confirmed, Signed, Not a high hand.
RoomDirectorA managed screen with filters and an audit path from call to signature.
TableCaptainHigh hand exists only as display content, a marquee row templating the latest hand and prize onto a screen.
This is a strong one. They can show a high hand. We can adjudicate, sign and audit one.
Service requests raised at the table
Architecture win
Both products have service requests. They are built the opposite way round, and ours is the better model.
RoomDirectorThe dealer raises it from the dealer app. It arrives live at the floor as a toast plus a header indicator, with urgency: a high hand outranks a drinks run.
TableCaptainThe floor person presses Chips, Drinks, Massage or Security on the table screen. All four are equal weight.
Why ours is better: the dealer is the person who actually notices. Theirs requires the floor to already be at the table, which is the moment the request was supposed to save.
Player self-service
Verified gap
Players join, hold and leave their own waitlist place from the mobile app, and get a seat-ready message.
RoomDirectorThe waitlist distinguishes a walk-in from a mobile join, and handles "player self-removed from the mobile app" as a real state.
TableCaptainStaff-entered only. Their self-service is a QR code on the wall board pointing at PokerAtlas registration.
Dealer downs and shifts
Verified gap
Downs per gaming night, time on downs, floor corrections with an add and remove trail, staff shift management, and a dealer-facing "my shifts" view.
RoomDirectorThree screens plus dealer self-serve.
TableCaptainA Dealer Rotation menu item. Never opened.
Satellite tickets
Verified gap
Issue, track, expire, and void with a mandatory reason. Nothing equivalent appears anywhere in their menus.
Room-controlled branding and content
Verified gap
Logos, theme, favicon, per-table logos and themes, custom pages, embeds, kiosks, streams, promotions and a Live Cards generator, all self-serve.
RoomDirectorA content system a room operates itself.
TableCaptainMarquee strings and a venue logo. A Promotions menu item, never opened.
Richer floor layout editor
We are ahead here
This surprised me. Their floor map editor looked strong until ours was measured beside it.
RoomDirectorDrag canvas, zones, multiple named layouts, bulk multi-table actions, generated layout grids, canvas sizing, fit-selection, per-table max players and per-table theming.
TableCaptainDrag canvas, sections, active and inactive state, zoom and recenter, and pit tables.
Their only edge in this area is pit tables.
Zero install
Structural
We are a web app. They ship an installed Windows and Mac client with a connection-settings step, a login, and a central auto-updater pinning which build each room runs.
Worth leading with in a sales conversation. Their model means IT involvement, per-machine installs, and version drift across a room's terminals. Ours means a URL.
QR scan flows
Verified gap
Scan player card, scan tournament, scan confirmation, plus a printable registration receipt. They have a Scan Receipt menu item, never opened, and employee badge scanning.
Where they lead
9 verified gaps
Every item here was checked against our code across all TableMaster repos, not just the room app. The pill states how much it matters.
Must-move
Close this one
A search for must.?move across every TableMaster repo returns nothing. The concept does not exist in our product.
RoomDirectorAbsent entirely.
TableCaptainFirst-class in three places: a banner on the game column header, an MM badge on the table in the floor view, and a per-player setting on the waitlist entry.
Why it matters: must-move is standard practice in any room spreading more than one table of a game. A floor manager evaluating us will look for it early, and not finding it reads as "they have not run a real room".
Multi-list enrollment
Close this one
One player queued for many games at once, with position shown as a fraction across lists.
RoomDirectorOur waitlist is per-stake. No cross-list count or position.
TableCaptainA Waitlists (3) count on the player panel, every enrolled game as a chip, and position as 1/2 or 2/2.
Why it matters: players routinely wait for two or three games. Without this the floor tracks it in their head or on paper.
Cashier and cage
Leave it
They have a Cashier module and a per-employee Transaction PIN separate from the login password.
RoomDirectorNone. Our code treats "the cashier window" as a physical place: comments state that rebuys and buy-ins happen there and the cashier tablet is the reconciliation surface.
TableCaptainMoney handling inside the app, PIN-gated.
This is a deliberate choice, not an oversight. It is written into our code comments as a decision. Taking money into the product means compliance surface. Do not close this gap by accident; close it only as a strategy call.
Patron tier and alerts on the floor panel
Worth doing
Their player panel shows Role, Tier and an Alerts row right where the floor person is working.
RoomDirectorWe have the richer underlying data (points, leaderboard, history) but it is not surfaced on the waitlist panel.
TableCaptainThinner data, better placed.
Cheap win. We already have the data. This is a placement problem, not a build.
The seat ring, everywhere
Worth doing
A numbered seat ring around a marked dealer position, clicked directly. They reuse one component in Seat Player, Current Location and Requested Location.
RoomDirectorWe have seat maps, but only in the tournament floor panel and the phone floor view. Cash seating does not use one.
TableCaptainSame picker in every seat dialog, learned once.
Cheap win. The component exists. It needs pointing at the cash surfaces.
Occupancy versus game-colour toggle
Worth doing
One floor map, two colour modes, one toggle: what is running where, or where there is room.
RoomDirectorOccupancy appears across 16 files, so the data is there. No single-toggle re-colour of one map.
TableCaptainVIEW GAME COLOR and VIEW OCCUPANCY.
Employee badges and per-person audit
Matters for regulated rooms
Attach badge, print card, scan employee, plus Audit Trail and Activity tabs on each employee record.
RoomDirectorWe have an activity log and roles, but not badge issuance or a per-employee audit view.
TableCaptainBadge lifecycle end to end, and per-person history.
Marquee dynamic-string engine
Partial overlap
Typed marquee records (Text, Jackpot, Rotation, Venue, DynamicString) where a jackpot row binds to live values and templates them onto the board.
RoomDirectorWe have a content and pages system, which is arguably more flexible, but no equivalent typed live-value binding.
TableCaptainImport, export, layouts and a string editor over the typed rows.
Pit tables
Only if we sell to casinos
Non-poker pit tables placed on the same floor map. Absent from all our repos.
Matters only when the buyer runs a poker room inside a wider casino floor. Low priority unless that is the pipeline.
At parity
Execution, not existence
Both products do these. Neither side wins the feature; a demo would be decided on how it feels.
Cash waitlistBoth queue, order, call and seat. Ours adds an Interest list; theirs adds bulk reordering.
Live tables viewBoth draw the floor with seats, occupancy and per-table actions.
Seat and move playersMove to another table, vacate a seat, close a game.
Role-based accessOurs is a min-role model; theirs is named role checkboxes. Both real.
Staff directoryBoth manage users, roles and deactivation.
Wall displaysBoth drive browser-based boards. Ours has kiosks and streams; theirs has .bat launchers.
Multi-venueBoth are multi-tenant with per-room configuration.
Audit metadataBoth stamp created, modified and by whom on records.
What I would do about it
Ranked
Ordered by how much a room operator would notice the difference, not by build cost.
Build must-move
The only gap that would actively cost us a deal. Needs the concept on the game, a badge on the table, a flag on the waitlist entry, and the seating rule that follows from it. Nothing to reuse; this is net new. Filed as TM-630.
Let one player sit on several lists
Second most visible gap, and it changes the waitlist data model, so it is better decided early than retrofitted. Pair it with a cross-list position display. Filed as TM-631.
Surface tier and alerts on the waitlist panel
We already hold better player data than they do and we are not showing it where it counts. Placement work, not a build.
Point the existing seat ring at the cash surfaces
The component is already written for tournaments. Reuse, not build.
Add the occupancy and game-colour toggle
The occupancy data already exists. One toggle over the floor map. Small, and it demos well.
Decide the cage question deliberately
Not a build task. A call on whether TableMaster ever touches money, made once and written down, so it stops reading as a gap. Matt's call, not a backlog item.
Method and caveats
Read before quoting
Three things that could make this wrong
1. Their side is a floor, not a ceiling. The recordings show builds 2.0.5 and 2.0.6. Their own back office lists client versions to 2.4.1 dated October 2024. Anything listed, they have. Anything added since is invisible to us, and roughly two years of it is missing.
2. Their side is only what was demonstrated. Twenty-two menu items were never opened, including Cashier, Dealer Rotation, Tournament, Analytics and Promotions. Where a "we lead" claim rests on an unopened menu, it says so on the card. Do not use those in marketing without checking.
3. Our side is read from code, not from a running app. Built is not the same as shipped, enabled, or good. Every "we have it" claim here means the code exists in the repo, nothing more.
Their inventory came from 270 frames pulled off six silent screen recordings; the full teardown with per-feature evidence is the companion document. Our inventory came from the route map and view layer of tblmaster-room, with every claimed gap re-checked across all TableMaster repos before being called a gap. Two claimed gaps did not survive that check and were removed: we do have service requests, and our floor layout editor is ahead of theirs.
TableMaster · Competitive comparison · TM-151
31 August 2026 · Internal
Their side: TableCaptain 2.0.5 / 2.0.6 · Ours: tblmaster-room, main