Building CUTE: what a two-person team learned shipping a Facebook Instant Game

Public product histories tend to keep the big numbers and lose everything that came before them. CUTE is worth writing about precisely because it was earlier, smaller and built by two people. It shows the conditions under which the later experience was picked up.

The listing that survives identifies it as a Casual, Trivia and Word game published in December 2018. An archived tracker later put it at roughly 250,000 players a month, though that is a third-party estimate rather than a number from our own analytics.

The game itself is offline and only a handful of screenshots survive. So this is about the product and the way we worked, rather than a detailed tour reconstructed from an incomplete archive.

A small team is not just a slower version of a big one. It carries a different kind of risk. The same two people who build a feature also test it, deploy it, read the analytics, answer the emails when it breaks and decide what happens next.

So what a feature costs to keep matters more than what it costs to build. Something you can add in a day but that generates a permanent stream of content, moderation or support is usually a bad deal. The version that survives is the one whose full surface fits the team you actually have.

Facebook Instant Games gave us leverage we could not have built ourselves. It ran in the browser, handled identity, sat inside conversations and needed no app install. The right move was to lean on that and keep the game itself small enough that either of us could change it without hesitating.

With two people there is no room for requirements to travel through documents and meetings, which is an advantage as long as the loop stays honest: notice something, agree the smallest useful change, ship it, look at what happened.

The trap is replacing process with memory. Even two people need to agree on what the important number is, write down what changed in a release, be able to deploy the same way twice and keep a short list of what they are currently betting on. That much structure makes you faster, because you stop rediscovering the same decision.

The tooling that helps is boring. Automated builds, a checklist before going live, error reporting and a few events you trust will do more than an internal platform that becomes another thing to maintain.

A player who opened your game from a Facebook post has invested far less than someone who searched an app store and waited for a download. That is the opportunity, and it is also the constraint. You have much less patience to spend.

Keep the download small, make the first thing to do obvious, and give the player something worth having before asking for permissions, a share or a paragraph of explanation. Social features land much better once someone understands what will be sent and why their friend would care.

That is design and engineering at the same time. A slow first screen changes the funnel, and a heavy asset pack quietly decides which phones and which countries can play at all. On a platform like that, file size is part of the onboarding.

The platform did work that two people could not sensibly have reproduced. It also controlled review, discovery, how identity worked and what we were allowed to send to players. Those are not paperwork details. They decide what you can build and who stays.

It is worth keeping that dependency visible. Write down what you are assuming, keep platform-specific code in one place where you can, and know which failures still leave the game playable. Above all, do not mistake the platform’s reach for a relationship with your players that belongs to you.

CUTE and everything that followed it benefited enormously from Facebook’s distribution. The fact that none of them are online now is the other half of that sentence.

The awkward part of writing a retrospective years later is not finding the code. It is reconstructing what players actually saw: the screens, the store text, the launch date, which languages shipped, what the numbers meant and why a particular decision was made.

A modest archive is enough. Six things, captured while the product is still live:

That is plenty to support a case study later, without exposing anything private about customers or players.

CUTE’s thin public footprint is now part of its lesson. Shipping matters, but keeping enough evidence to explain what you shipped is product work too.