DEV BLOG / 20
Building a private league you can share
One league needs one authority, even when several coaches are looking at it.

The desktop and phone work raised another question: what happens when more than one person manages the same football world?
This is the private-league work. It adds a separate server and communication around the existing football systems. It also adds plenty of ways for two screens to disagree, which is not the kind of rivalry I’m trying to build.
What changed since the platform update
- A dedicated server owns the league state. Drafts, scheduling and management commands go through the same authority.
- Accounts and sessions identify the coach. Franchise ownership and the correct league context govern the actions available.
- Commands can be retried safely. An interrupted connection shouldn’t turn one accepted transaction into two.
- Clients receive updates and can reconnect. Published frames and changes rebuild the current view while keeping separate leagues isolated.
- Invitations have a complete join path. One-use authenticated tickets, copy-and-paste joins and app-link intake work with saved server trust and protected credentials.
- League communication has its own screens. Private and global chat, blocking, trade counteroffers and shareable Franchise Cards are part of the source work.
- The League Office has host controls. Local process control and a secured remote-console route support private hosting.
- The Windows companion delivery grew. Full-height docking, hide and reveal, expanded workspace, tray controls and a saved ticker preference have recorded packaging work.
- Phone actions have clearer outcomes. Successful external report handoff can close the form, while failures preserve the text and copy fallback.
- Joe’s chat is less eager with the keyboard. Opening conversation doesn’t force typing, and Send releases focus; complete reply behavior still needs its own check.
Joining the right world matters
An invitation should join the league it was issued for, under the correct coach and server context. It shouldn’t reuse a stale screen’s assumptions. A retry needs to preserve the accepted result rather than repeat its financial effect.
Those aren’t particularly glamorous paragraphs for a game blog. They’re the parts that matter before I invite somebody else to trust a franchise they’ve spent time building.
Keep the claims modest
The server and interface code cover a lot of ground. I still need to establish that actual clients stay in sync, join and reconnect properly, and use the deployed services reliably. A server project compiling is encouraging; it doesn’t finish those jobs.
The companion still needs its routes, forced-exit cleanup and final layouts checked. I want it to be useful, but I still need to earn confidence in it.
I’ve developed rather more respect for the little “reconnecting” label in other games.
Next week brings me back to the local interface: blinking portraits, clearer navigation and a broader attempt to make the menus feel less like my filing system.
