Rebuilding from the Inside Out

PsTally was working. That was the problem.

When something is broken, the decision to rebuild is easy. When something is working — real businesses running on it, real shifts opening and closing, real cash being reconciled every night — the decision is harder. You are not fixing a failure. You are choosing to interrupt a functioning thing because you can see what it cannot become.

PsTally was running on WordPress Multisite. It had real users, real sessions, real money passing through it. It also had a Lighthouse score of 56, no proper OG images, no SEO structure, no public profiles, no path to what the product needed to be next. The architecture wasn't broken. It was limiting.

The ceiling was visible. I decided to move before we hit it.

The rebuild was not a technology swap

Most developers approach a rebuild as a migration — same product, different stack. Move the features, replicate the logic, update the dependencies. That is the wrong frame.

A rebuild is the last moment before the architecture locks again. The decisions you make in the first week shape everything that follows. If you rebuild without rethinking, you carry the old assumptions into the new system and the ceiling reappears six months later, one layer higher.

The PsTally rebuild was a GTM engineering project. The technology was Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, tRPC. That choice took an afternoon. The real work was answering a different question: how does this product grow?

Every feature was designed with distribution in mind. The demo. The public tournament profiles. The organizer landing pages. The WhatsApp shift reports. None of these are afterthoughts. They were engineered during the build, not added after the product was finished. By the time PsTally launched on the new stack, the acquisition layer was already inside the product.

Zero downtime with 1,368 sessions live

The hardest constraint was not technical. It was human.

Fifteen gaming lounges were running on PsTally. Shifts were opening at 10am. Sessions were being logged throughout the day. Cash was reconciling at midnight. None of that could stop.

The migration happened one lounge at a time. For a period, both systems were live — the WordPress system receiving events, the Next.js system receiving the same events in parallel. Each lounge moved when their window opened: between midnight and 6am, when sessions were unlikely to be active. The monitoring script was updated to point at the new endpoint. The session history — 1,368 sessions, Ksh 156,000 in revenue records — was migrated with a script that validated every row before committing.

Zero downtime is a constraint that changes how you architect the migration. You cannot flip a switch. You have to build a bridge, cross it one person at a time, and dismantle the old structure only after the last person is across.

The monitoring system

The part of PsTally that is hardest to explain is the part that matters most.

Gaming lounges run on trust — and trust breaks down when you can't see what's happening. A console that has been running for three hours with no session logged is either a gift session or a ghost session. Both cost the owner money. Neither is visible in a simple session log.

The monitoring system watches from the outside. A Windows Electron app runs silently on the lounge PC — no UI, no interaction, just a background process feeding console state to the cloud every five minutes. PS5 activity is detected via UDP port 9302. PS4 and Xbox activity is tracked through network heartbeats. If a console is active and no session exists for it, a ghost alert fires. The owner sees it on the dashboard before they would have seen it on any report.

The dashboard doesn't display the alert. It surfaces it. There is a difference. A display requires the owner to be looking. Surfacing means the information finds her.

The system watches without being watched. That is what it was designed to do.

The demo as a distribution channel

An empty demo environment communicates nothing. It asks the prospect to imagine. Imagination is work. Work is friction. Friction is lost conversions.

The PsTally demo is seeded with seven days of realistic data — shifts, sessions, cashouts, expenses — rebuilt every night at midnight by a cron job. Every visitor who enters the demo sees a functioning business, not a blank canvas. The owner dashboard has numbers that move. The AI chat has history to query. The analytics show a heatmap with actual patterns.

A prospect who enters the demo is not evaluating features. They are running a lounge that already exists. The decision they are making is not whether the software works. It is whether they want their own version of what they can already see working.

Try it at pstally.com.

The dashboard that surfaces meaning

Most dashboards display data. The PsTally owner dashboard was built to surface intelligence.

Revenue trends, peak-hour heatmaps, console performance breakdowns — these are expected. What isn't expected is an AI chat interface that lets an owner type "how much did James make last week" and get a real answer from their own data. Or a ghost alert that fires before the owner would have thought to check. Or a shift summary that arrives on WhatsApp before the staff member has finished counting the cash.

The dashboard was designed around a specific question: what does the owner need to know right now, before they know to ask? Every feature answers that question or it doesn't belong in the interface.

56 to 91

The Lighthouse score moved from 56 to 91 in the rebuild. That number is not a vanity metric.

A score of 56 means the product was invisible to search engines and slow for users. Every session started with a wait. Every potential customer who found PsTally through a search got a poor first impression before seeing a single feature.

A score of 91 means OG images render correctly when a link is shared on WhatsApp. It means the marketing pages load before the user decides to close them. It means the product can be found by someone who doesn't already know it exists.

The technical work and the marketing work are the same work. The Lighthouse score is not a developer metric. It is a distribution metric.

What I would do the same

Build the GTM layer during the product, not after it.

The tournament system has public organizer pages because I designed them into the rebuild, not because a user requested them six months later. The WhatsApp reports exist because I knew the acquisition path before I wrote the first line of code. The demo is seeded nightly because I understood that the demo is not a test environment — it is a sales tool.

If you are rebuilding a product and you are not asking how it grows at the same time, you are solving half the problem.

What changed

The notebook is still on the counter in some lounges. They haven't opened it in months.

PsTally is live at pstally.com. The demo is open. The shifts are running. The monitoring is watching.

The platform was rebuilt for what comes next.