Building TawlaLeague: lessons from shipping our own product

We built TawlaLeague because we wanted to — not because a client asked us to. That distinction matters more than it might sound. When you're building for a client, someone else absorbs the consequences of your product decisions. When you're building for yourself, you find out fast which ones were wrong.

Why a league platform for Tawla

Tawla (Middle Eastern backgammon) is played competitively across cafes and clubs throughout the region, but the tooling around organising leagues — tracking standings, scheduling matches, handling disputes — was still largely manual: spreadsheets, WhatsApp groups, and someone's memory. That gap, and our own connection to the region, made it a natural first product to build.

What we got right

Starting narrow. The first version did exactly one thing: track a league's standings and match results, with real-time scoring. No user accounts beyond what was needed to run a league, no monetisation, no admin dashboard beyond the basics. Shipping something narrow and real beat a broader, half-finished version every time we were tempted to expand scope before launch.

Multilingual from day one, not bolted on. Given the target market, English/Arabic support was a structural decision from the first commit — right-to-left layout considerations, font choices that render Arabic script properly, and content structured so translation didn't mean rebuilding pages. Retrofitting this after launch would have cost far more than building it in from the start.

Real-time scoring as the differentiator. The existing alternative — spreadsheets updated after the fact — meant players and spectators never knew live standings during a session. Solving that one problem well mattered more than a long feature list.

What we'd do differently

We underestimated onboarding friction for club organisers. The product itself worked well once set up, but the initial setup flow assumed more technical comfort than many club organisers had. The lesson: the person managing a league on a Tuesday night in a cafe is not your ideal user for testing an admin flow — test with the actual, less technical audience earlier.

Feedback loops matter more than roadmap discipline. We had a roadmap. We mostly didn't follow it, because early user feedback kept surfacing more urgent things — and that was the right call. A roadmap is a hypothesis, not a commitment.

Why this matters for client work

Every lesson above now shows up in how we scope and deliver bespoke software for clients: start with the narrowest version that's genuinely useful, build in the requirements that are expensive to retrofit (localisation, data model decisions, integration points) from day one, and treat the delivery roadmap as a living document, not a contract to defend.

Building our own product means we've made these mistakes with our own time and money first — which is exactly the kind of experience we bring to a Discovery Workshop before your project starts, not after it's already scoped wrong.