What I Got Wrong the First Time I Built PsTally

The first version of PsTally worked. Operators used it. Sessions got logged. Revenue got tracked. By any functional definition, it was a product.

It was also wrong in almost every way that matters for a SaaS business. Not wrong in a dramatic, spectacular way — wrong in the quiet, structural way that means a product will always have a ceiling it can't break through.

Writing this is uncomfortable. That's exactly why it's worth writing.

I built features before I understood the acquisition path

The original PsTally was built on WordPress Multisite. Each gaming lounge got a subsite. I had a session timer, a revenue dashboard, console management, a basic staff view. The features were real. They solved real problems.

What I didn't have was any coherent answer to: how does a new customer find this and decide to pay for it?

I assumed that would sort itself out once the product was good enough. It does not sort itself out. The acquisition path is not a marketing problem you solve after the product is ready. It is a design constraint that should shape what you build from the first commit.

If you're acquiring through search, your product needs public-facing pages that can be indexed. If you're acquiring through referral, your product needs to be shareable in a way that creates visible proof of value. If you're acquiring through outbound sales, your demo needs to be compelling in a two-minute screen share. I had thought about none of this while building. The product had no mechanism to grow.

I let the architecture limit the product

WordPress Multisite was the wrong foundation and I knew it, at some level, earlier than I admitted it. The performance ceiling was real — Lighthouse scores in the mid-50s, page loads that felt slow on the mobile connections my operators were actually using. The data model wasn't designed for the queries I needed to run. Every new feature required working around the architecture rather than with it.

The thing about letting the wrong architecture persist is that it doesn't fail loudly. It fails slowly. Each feature takes longer than it should. Each performance improvement costs more than it returns. The product never feels fast because it structurally cannot be fast. You adapt to it. You start thinking in terms of what the architecture permits rather than what the product needs.

The rebuild to Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, and tRPC was not a nice-to-have modernisation. It was the decision to stop letting the foundation set the ceiling.

I didn't design the demo as a sales tool

The original PsTally had a demo that was essentially a staging environment. You could log in and poke around. The data was sparse and obviously fake. There was no seeded history, no realistic patterns, no sense of what it would feel like to actually run your lounge through this product.

The implicit message of that demo was: trust me, it works. That is the weakest possible pitch. Nobody should have to trust you before they've felt the thing for themselves.

I've written elsewhere about what the demo should be. But the honest version of why I didn't build it right the first time is simpler: I thought the product's job was to work, and the demo's job was to show that it worked. I didn't understand that the demo's job is to make the prospect feel what it's like to have the problem already solved.

A Lighthouse score of 56 means the product is invisible

A Lighthouse performance score of 56 is not just a technical metric. It is a distribution failure.

It means the product loads slowly enough that operators evaluating it on a mobile connection click away before they've formed an opinion. It means Google's crawlers evaluate the pages as low-quality and suppress them. It means the product is invisible to the search surface that could have brought operators to it organically.

I understood this abstractly while building on WordPress. I didn't feel the urgency of it until I looked at the data and saw how little organic traffic the product was generating despite genuine effort on content. The architecture was absorbing effort that should have been compounding.

No public profiles meant no organic discovery

Every gaming lounge using PsTally was invisible to the web. There were no public pages. No lounge profiles. No way for a player in Nairobi searching for a gaming lounge to find a PsTally operator and, through that, find PsTally itself.

This was a missed distribution loop. The product had users. Those users had customers. Those customers were searching the web. There was no connection between any of these things.

The right architecture would have made every PsTally operator a node in a discovery network. Players finding lounges would have been finding PsTally at the same time. The product would have been growing its own reach through its users' usage. Instead, the product was invisible to everyone except the operators already using it, and acquiring new operators required effort that produced no compounding return.

No tournament system meant missing an obvious use case

Tournaments are how gaming lounges create community. They are the event that fills all the consoles on a Saturday afternoon. They are what operators talk about when they talk about wanting to grow their business.

PsTally didn't have tournaments. I knew operators wanted them. I kept deferring the feature because it felt complex and I was busy with the core functionality. The result was a product that solved the operational layer and missed the growth layer entirely. Operators had a session tracker but no tool for the thing they actually wanted to grow.

What I actually learned

The product and the marketing are the same problem. I understand this now in a way I didn't when I was building the first version. The decisions you make about architecture, public-facing pages, the demo, the features you prioritise — all of these are simultaneously product decisions and distribution decisions. You cannot separate them. Trying to solve them in sequence, product first and distribution second, produces a product that works and doesn't grow.

The rebuild wasn't just a technical upgrade. It was the decision to treat the product and its market as a single design problem. That shift changes what you build, when you build it, and what you refuse to build until the foundation is right.

The most expensive thing I did in the first version of PsTally was defer the hard questions. What is the acquisition path? Who discovers this and how? What does the demo need to feel like? Those questions felt like marketing questions. They were engineering questions. I just didn't know it yet.