What building a product on my own taught me about client projects

Since late 2025 I have been building LudoExplorer, a board game recommendation site, on my own, from a public data export to a live server. I wrote down what went wrong and what I learned from it in a series of ten articles on Medium. Those articles are technical. This one keeps the six lessons that also apply to a client project, with or without code.

Decide what the data is for before you clean it

The public export I started from held about 125,000 entries. It answered the question of what the source keeps track of. My visitors ask a different one: what could I play? Promotional items, extras from crowdfunding campaigns and duplicate editions had no place in that answer. The catalogue on the site keeps about 90,000 games.

Before cleaning anything, I wrote a data dictionary: one line per column, with what it means, how it has to be transformed and whether it may be edited. It took an afternoon, and the document later drove the editing tool I built for the data.

The same goes for a CRM export or a product file. "Everything in the export" is not a requirement. Start from what the user needs from the data, and filter against that.

Read part 1 on Medium: I broke my own dataset

Labels are part of the interface

The source describes each game with labels. One type of label, families, has 5,295 values. Catan alone carries 17 of them, and only 3 say what the game is about. The rest matter to a collector and are noise to someone choosing a game for Saturday evening.

I built my own classification on top, with broad groups for browsing and precise labels for detail. It took several corrections. My first keyword rules filed a soap opera under a group about the play experience. A group with a single option looked odd on the screen even though the data was right. Two things that shared a name were taken for the same thing.

Categories, statuses and product types in a business tool work the same way. People read them as part of the screen. Classify the way your users search, and read the result group by group.

Read part 2 on Medium: 5,295 families and no themes

When you can't guess what someone wants, let them say it

In the same search box, visitors type two different things: the name of a game, or an idea, such as a cooperative game with animals for four players. For months I tried to detect automatically which of the two it was. Every rule I wrote broke another case.

In the end I stopped guessing. The search page now has two modes, one to find a game by name and one to explore from an idea. It also shows how it understood the question, so the visitor can correct it.

I know this rule from business analysis, and I still had to learn it again on my own project. When a need cannot be inferred reliably, a simple question works better than a clever guess.

Read part 5 on Medium: A game or an idea? Building search in three languages

Count what people do, not page loads

I built my own visitor statistics for the site. In the first four weeks of September 2026 they counted 259,106 sessions. Only 136 of those contained an action beyond loading a page, such as a search, a filter or a click on a game. Nearly all the rest consisted of a single page load, most likely automated traffic.

The first figure looked like a growing site. The second is closer to reality, and it is no surprise for a site I have not promoted yet. What did surprise me is how convincing the first figure looked.

Before a dashboard steers a decision, define what a real visitor or a real customer action is, and count that. So far my statistics have mostly helped me catch errors, not steer the product, and I prefer to say so.

Read part 7 on Medium: My analytics counted 259,000 sessions in a month. About 140 were people.

Once people use it, stop rebuilding

At first, every data update rebuilt the whole database from the source file. That was fine as long as the database only held the catalogue. Once it also held visitor data and contact messages, a rebuild would have erased them with no way back.

I built an update path that changes the catalogue and leaves everything else alone, with a trial run that reports what would change before anything is written. I added nightly backups stored elsewhere, and written procedures for the operations I carry out less than once a week.

As an analyst I write that kind of document for clients. On my own project I resisted it at first, because I knew the system. Six months later I no longer knew it in the detail an operation in production requires.

Read part 3 on Medium: A 300 MB database that needed 2 GB to build

Read part 9 on Medium: One server, 7 euros a month

An AI assistant makes clear requirements more important

I worked with an AI coding assistant throughout the project. It helped most with documentation and with laying out options so that I could decide. It was also able to argue convincingly for a wrong conclusion.

A review it wrote proposed a fix that looked like a single line. I measured first. The fix would have rewritten 5,441 correct search keys into a form the search could never have matched, and erased 147 search terms I had written by hand. It was not applied.

An assistant acts on what you write, quickly and literally. Working out what the need is and stating it precisely, which is the core of business analysis, turned out to be what made the assistant useful. And the rule holds for any explanation, mine included: measure before believing.

Read part 10 on Medium: From debugger to project partner

The full series

The ten parts also cover the recommendation models, the application itself, visibility in search engines and hosting. The full list is on the LudoExplorer project page, and the site itself is at ludoexplorer.com.