In this second (and final) part, I cover the implementation of the new Daily Challenge mode, specifically

• how it works

• answer validation and caching

• scoring and leaderboards

• automated daily/weekly summaries

Welcome!

With the architecture in better shape and an improved UI, I added something new: a game mode that would keep players engaged with the app, even if they had no one to play with. In the Daily Challenge mode, every player gets the same letter and categories each day. You have 30 seconds to fill in your answers, which are then validated by an LLM.

LLM Validation

This was the answer to the most important question of the game mode: how would the answers be validated? In normal PvP gameplay, answers are graded by players and disputes are resolved outside the app (players could argue about it on a phone call, for example).

This wouldn’t work for a Daily Challenge mode. And unlike other word games where challenges have specific solutions used to validate players’ submissions, a letter+category combination in ICallOn could have several valid answers.

The solution here was to rely on an LLM. With good prompts, LLMs excel at category validation and I chose Google’s Gemini 2.5 Flash model for this purpose.

There were some cost considerations in this decision. Gemini has a generous free tier, but I eventually hit its daily request limits and upgraded. So far, costs have stayed comfortably low.

To preemptively minimise costs, I added a caching layer that stores validation results in the database.

Since release, I’ve cached 500+ validations and avoided ~200 same-day duplicate LLM calls which saves tokens (and money).

Scoring

Scoring in a PvP ICallOn game is straightforward. You get 10 points for a unique answer, 5 for a duplicate, and 0 for an invalid answer. In the Daily Challenge mode, such a scoring formula would not work because the frequency of duplicates could vary significantly, and the points penalty should be proportional to that variance.

Therefore, the scoring goal (pun intended) was to give unique answers a perfect score (10), and assign a score in the range of 1 to 9 for a duplicate answer such that the higher the frequency of duplicates, the lower your score.

I considered three ways of doing this

1. Direct Deduction: for every duplicate of your answer, you lose a point. It’s simple, intuitive, and ideal for a small pool of players. If 3 other players submitted the same answer, you each score 7 points (3 points lost).

2. Proportional Deduction: the deducted points is based on the proportion of players with the same answer as you. It’s less intuitive, but great for mid-sized pool of players. If 3 other players submitted the same answer and there were 16 players in total, you each lose 3/16 * 10 points. And if there were more players in the pool, then the penalty is reduced.

3. Exponential Deduction: it’s similar to Proportional deduction, except that many duplicates are punished more harshly than fewer duplicates using an exponential function.

I settled for Direct Deduction for two reasons. First there aren’t a lot of players, so simple and intuitive rocks. Second, it’s not hard to imagine scenarios with the Proportional and Exponential Deductions where approximations would be required, and perhaps even result in fractional scores. It’d take some explaining for players to understand that their low score is because 65% of the players tendered the same answer they did.

One important detail is that scores are recalculated as new submissions come in. If Taiwo submits the same answer you did later in the day, your points drop accordingly. That means scores (and ranks) can shift throughout the day, and the leaderboard only settles at day’s end.

Subscribe now

Leaderboard

Players are ranked on the leaderboard by their points tally. If two players score the same, then the player with the fastest submission edges it. So while each challenge lasts for 30 seconds, players are encouraged to submit quickly.

For ICallOn v2, I added three leaderboards

• Daily: shows player rankings on the present day

• Weekly: shows player rankings for the present week (Monday - Sunday, UTC)

• All Time: shows player rankings since the Daily Challenge started

I did consider a Monthly Leaderboard. Over time, perhaps it’d be more useful than the All Time Leaderboard.

Usernames

Since ICallOn v1, authentication has been via Google and it remains so. Users needed to sign in to create game sessions, but players could join existing sessions anonymously. For the Daily Challenge mode, authentication is required so that scores can be attributed consistently. This can be changed at any time on a new Profile page I added.

Sharing Results

Like other word games with daily challenges, part of the fun is showing off your undeniably good or embarrassingly poor performance. As such, players can share their gameplay results which includes the following

• Points per category

• Total points

• Rank

• Time Taken

To prevent spoilers, I don’t include the letter, categories, or answers.

Question Bank

Each daily question includes a letter and four random categories (from a growing list of 11 categories). The questions are seeded in a question bank, and the application serves players the question of the day.

Automated Summaries and Tweets

Since developing ICallOn, I’ve shared updates about the features and rollout on Twitter via @wolemercy. After deploying the daily challenge feature, I figured it’d be great to make commentary on the leaderboard, and highlight any notable rank changes from day to day. It would also be fun to highlight the player of the week, I thought.

Since the Daily Challenge can be taken at any time, and a player’s points and rank can change at any point during the day, it meant the daily leaderboard was only set in stone at midnight. As such, leaderboard analysis could only happen the following day. To make this work, I needed three components: a summary generator, a Twitter posts integration, and a cron job.

Generating Summaries

As with answer validation, I relied on an LLM for summary generation. First, I fetch the leaderboard data (daily or weekly, as the case may be). If it’s the daily leaderboard, I also compute rank changes, which compares each player’s current rank with their rank the day before.

This data is fed into a prompt that I send to an LLM (gemini-2.5-flash). If this fails, it falls back to a hardcoded template summary.

In addition to the text summaries, I also generate a leaderboard image of the top 5 players, and it’s posted alongside the summary.

Twitter Posts

I created a twitter account specifically for ICallOn @icallon_xyz, for tweeting these summaries. To achieve this programmatically, I make two calls to Twitter’s API for each summary tweet. The first call uploads the leaderboard image, while the second posts the tweet.

Cron Jobs

To generate and post tweets on schedule, I rely on Vercel Cron, which fires at 8 AM every day for the daily tweets, and 8AM every Monday for the weekly tweets.

Wrapping Up

ICallOn has seen a lot of changes from v1 to v2, and I’m hard-pressed to see any other major additions I could make. The PvP mode provides an experience that embodies the spirit of the traditional game. And the Daily Challenge mode, which was one thing I’d always wanted to add, provides a way for players to compete with others every day.

One thing I would like to do is make the game snappier. There are certain transitions within the app that could be faster, which would make for a better gaming experience. I would also like to handle certain failure scenarios better, such as an LLM failure during answer validation.

Thank you for following along. Please, check out the game if you haven’t already: www.icallon.xyz. And if you have any feedback, feature requests, or general comments, please tweet me @wolemercy.

Thanks. See you around.

- Wolemercy

P.S Read Part 1 here

Thanks for reading! Hope you hang around for more Software Engineering posts.

Subscribe now

In building it, I wasn’t trying to reinvent the game. As such, it was important for me to preserve its core parts which were the way the “caller” rotates each round, and the small power they hold to end a round whenever they choose.

At launch, ICallOn supported the following:

1. Creating and joining game sessions

   1. Custom word categories

   2. 30/60/90 second timers

2. The core gameplay loop

   1. Selecting a letter each round

   2. Ending the round early as the caller

   3. Grading another player’s answers at the end of each round

3. Lobby and gameplay notifications

4. Game results and game history

To pull off the real-time multiplayer, I leaned heavily on WebSockets. It’s a protocol I’d read about, but never properly used in a project before. The tech stack (and deployment) looked like this:

1. Next.js — UI & API (Vercel)

2. Postgres — Database (Supabase)

3. Soketi — WebSockets (DigitalOcean)

In terms of cost, it was refreshingly simple. I only had to pay for the Digital Ocean droplet and the domain (icallon.xyz).

A few months later in May 2025, I hosted a Twitter Space where we (my friends and I) played ICallOn live. The game supports up to 10 players per session, so I had what I thought was a brilliant idea: I’d build a spectator view. That way, people who weren’t playing could still watch the game unfold in real time.

When the space actually happened, we were fewer than 10 people. We didn’t need spectators at all, and the feature was altogether unnecessary. I still think it was a brilliant idea though xD.

After that, I mostly left ICallOn alone. Every now and then, I’d ship a small improvement or fix a bug, and the game worked fine.

Over time, however, the app started to feel like a bare minimum game, mostly because it relied heavily on card components and stacked layouts. For a while, I’d been thinking about a proper upgrade. I wanted a second iteration of ICallOn that would include:

1. A major UI/UX refresh

2. Technical enhancements

3. A Daily Challenge mode

I finally got around to implementing these in the last month, and that’s what makes up ICallOn v2, which you can play here: icallon.xyz.

Subscribe now

UI/UX Refresh

ICallOn v1 used Mantine’s default components to a fault. Back then, the goal was to ship something that worked, so I reached for the quickest building blocks available: cards. I whipped out a card for virtually everything. A card for this, a card for that, a card for you, and a card for me.

For v2, the guiding philosophy was to replace the generic UI patterns with more game-native ones. Score cards became leaderboard rows with rank badges. Progress bars became little avatar grids. I added more depth with shadows, improved spacing, and sprinkled in a few animations so the app felt less like paperwork.

Some highlights:

• Tabbed gameplay navigation: Instead of stacking Game, Players, Rounds, and Info into one long screen, I moved them into tabs. There’s less clutter, and players can jump to whatever they need in one click.

• Custom score buttons: These went through several iterations. First it was a number input with increment(+) and decrement(-) controls. Then a Select with 0, 5, and 10. Now, I’ve made them buttons, and scoring is done with a click.

• Better loading experiences: In flows like creating a game or starting one, players now see a loading animation instead of wondering whether the app froze.

• Game results: Players always saw confetti when viewing Game Results and now, I’ve added a podium for the top 3 players in that game for a bit more drama.

I hadn’t originally planned to, but I also added some sound effects. You’ll hear them play on button clicks or after certain gameplay state changes (e.g. when a round ends or when time is almost up). You can toggle sound in the header, just beside the theme icon.

Technical Enhancements

One of the reasons I delayed working on v2 was that I wasn’t looking forward to cleaning up some of the bad code I’d written and correcting a few poor architecture decisions.

I group these issues into three buckets:

1. Ghost Events

2. God Classes

3. State Management

Ghost Events

In v1, the WebSocket events were emitted inside database transactions. When a game is started, for example, the database is updated. As part of that transaction, the game:started event is also emitted. This sounds fine, but if the transaction rolls back after the event has fired, players get notified even though the game state did not change.

To address this, I introduced the Event Outbox Pattern. Instead of emitting events inside transactions, I write them to an outbox table in the same transaction as the state change. If the transaction fails, no event record exists. If it succeeds, the event is guaranteed to be recorded. It is then emitted over the WebSocket.

God Classes

The dread I had for the v2 upgrade was mostly due to v1’s poor maintainability. On the backend, I had a GameService with ~2000 lines of code that handled everything: sessions, rounds, scoring, and event emission. God classes like this make debugging difficult. Reading the code feels like a chore, and you want to get out as soon as you’re in. It wasn’t code that was written by someone who cared.

In v2, the responsibilities of GameService were split into five focused services, the largest having just over 500 LOC. The original GameService became a thin facade (~200 loc) that delegates to these services.

Similarly, on the frontend, v1 had a GamePage component with several responsibilities, including WebSocket event handling, notifications, server actions, and rendering. I also decomposed it into more focused components, and the codebase looks much better.

State Management

In v1, I relied heavily on Next.js router.refresh() to retrieve the latest game state from the database whenever an event was consumed. I didn’t need to make this round trip. Silly me. The WebSocket events already contain the data the client needed to display, and I made the most of this in v2, reducing the round-trips to the server.

Additionally, state management on the client was a mess in v1. It was the classic case of prop drilling, which made the application buggy. Refetching data from the DB helped address these bugs, but it wasn’t the most efficient solution. In v2, I introduced a Zustand store for managing the game state. The server provides the initial state when the page is loaded, and after that, the client owns the state.

Wrapping Up

That was the bulk of the v2 upgrade, which wasn’t really about adding features. It was about making ICallOn feel like something you’d want to return to, and making the internals stable enough that I could build on top of them without fear.

In Part 2, I’ll talk about the new Daily Challenge mode, and the two questions it forced me to answer: how do you validate submissions without a human judge, and how do you score duplicates fairly when everyone is playing the same game?

In the meantime, you can check out the game here or tweet at icallon_xyz.

- Wolemercy

Thanks for reading! Hope you hang around for more Software Engineering posts.

Subscribe now

One Friday night in December, I sat at my desk ready to deploy the app I’d spent the week building. The stack was simple: Next.js for the UI and API, and a Postgres database. Given that it wasn’t intended to be a public-facing app, I saw it as my introduction to self-hosting applications. It’s what the cool kids are doing, after all. Seriously though, there is something deeply satisfying about controlling every aspect of your system except perhaps, the hardware, if like me your intention is to use a Virtual Private Server.

I had a Sunday deadline, and the plan was to spend the weekend in a wrestling match with the deployment. Yes, a wrestling match with some fun, drama, hair-pulling, timeouts, more hair-pulling, and my inevitable conquest.

In the course of the week, I’d also researched the best (read: affordable and reliable, especially affordable) VPS to use, as well as how to configure and manage self-hosted apps and services with minimal effort. I came upon the Hetzner + Coolify combo, which you may be familiar with if you’re into the business of hosting yourself. Hetzner’s servers are reasonably priced and their customer support is good, while Coolify simplifies the management of your deployments (and it can also be self hosted).

Cool. This was the way.

Subscribe now

Until it wasn’t.

I created an account on Hetzner, but it needed to be verified. That’s not a train smash, I thought. I just needed to upload my ID document.

“Ah, these are stiff KYC requirements, Mr. H,” I all but said to Hetzner.

I didn’t have much of a choice. I uploaded it, only to be told that verification requests are processed only during normal business hours. This was around 21:00 UTC on Friday. I would have to wait until the following Monday to get any form of feedback. Bummer.

I searched for alternative VPS providers, but I wasn’t convinced by them. Frustrated, I ditched the plan entirely and pivoted to Railway (which is its own story). It wasn’t much of a wrestling match in the end. I’d lost before I entered the ring. I’d lost to a KYC check.

The Hetzner story doesn’t end there. When Monday finally arrived, my account was deactivated because ”Mr. H” had some ”concerns” with the information I provided. I’m still not entirely sure what that meant.

As it turns out, my situation wasn’t unique. I reached out to them on Reddit, and they guided me through a re-verification process. My account was eventually verified a week to the day I signed up. Yeah, it took me seven days to get access to a VPS provider. And I’m not sure how I feel about it.

I hadn’t experienced such before, where I couldn’t simply sign up, pay for a service (SaaS/PaaS/Iaas), and use it immediately. On some level, I understand the need for KYC, especially to prevent servers from being used for malicious purposes, as this post hints. Yet, the whole process seemed like an overkill.

I’m not sure how they determine which accounts require ”extra” verification, or why a valid ID would be rejected so dismissively. It also didn’t help that the rejection seemed final. I mean, look at that mail. It reads like I was being served. I also had to do some digging to find a way to contact them, though, to their credit, they are responsive on Reddit.

Hetzner’s onboarding model likely works for them most of the time. But for decent users, waiting a week to be fully onboarded is a terrible experience. It’s a good thing I had an alternative, and so I got my deployment over the line. Perhaps a lesson here is that if you have any service you want to try over the weekend, don’t wait until Friday night to sign up.

Ultimately my foray into self-hosting was delayed—only delayed. I will be trying (read: wrestling) again soon. And there will be no KYC checks to stop me.

- Wolemercy

Thanks for reading! Hope you hang around for more Software Engineering posts.

Subscribe now

In the first chapter of Robert C. Martin’s Clean Code—a book about writing software that is easy to read, understand, and maintain, he takes a few stabs at the definition of clean code through the lens of other engineers. Each engineer described useful properties of clean code using words like elegant, efficient, simple, direct, and readable. However, the definition I found most striking was Michael Feathers’.

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft - Michael Feathers

This idea stayed with me. Care is the keyword here: “Clean Code always looks like it was written by someone who cares.” The book’s essence, then, is a lesson in caring for code. And although it is specifically about code, the lesson is transferrable to other aspects of life. I found myself asking how much care I put into the world: do I take care to do things? And you—are you full of care in the big things: your relationships, career, and health? Are you equally full of care in the little things—your conversations and routines? When you arrange saucers in the cupboard, do you stack them in order? When you write code and make a commit, is your commit message descriptive? How much care do you apply to things?

Your answer, like mine, is probably “not enough.” Every single thing we do, whether painfully mundane or remarkably grand, presents us with an opportunity to be careful in execution. Yet, as engineers, artisans, friends, parents, vendors, designers, and whatnot, we often fall short of carefulness. One common reason for this is the need to be fast, to finish quickly. This could very well be the case, but more often than not, it simply betrays a lack of ability—a skill issue, one might say.

Carefulness begins with intent and ends with competence. No amount of time will be enough if you do not intend to stack saucers in order, or if you do not know (and refuse to learn) how to do so. Yet intent and competence, even when joined, do not equal perfection; they merely make it possible. Perhaps this is where many of us stumble—we mistake competence for perfection, as though to care deeply is to get everything right. That is false. Carefulness doesn’t ask for perfection but for attention. We can tell when someone is giving us attention and when they’re not. In the same vein, we can tell when a piece of work has been suffused with attention and when it’s been starved of it. Perfection has little to do with it.

We should apply more care to the things we do. Since caring involves both intent and competence, we could learn to be better at it. How we care for people differs from how we care for code, which is different from how we might care for a spaceship, and so there is room for learning and growing. Ultimately, in our march towards cleanliness—towards carefulness—in our code, paintings, writings, relationships, designs, and anything at all—we go only as far as our competence allows us.

We can always apply more care to the things we do. It starts with intent and ends with competence. We march towards cleanliness—towards carefulness—of code, paintings, relationships, designs, by growing and learning.

Thanks for reading!