Knowing what to remove is design too

This is the fifth and last post in the behind-the-scenes series about Olha o Bichim!. In the previous ones, I talked about the idea, the specification, the execution and the rules. Now, the product.

So far, it may look like the project was a straight line: document, specification, plan, code, release. It wasn't. Many of the most important changes came from people playing and saying, bluntly, what didn't work.

Six months on one line

In April, the design document, the game engine and the visual identity. May was the most intense month, with 543 commits: the new name, the shop, the end-to-end tests, Firebase, the leaderboard and purchases. In June, sound, security and the redone tutorial. In July, the release on Google Play and the App Store. August was animations, coins, a new leaderboard and the press. September and October brought the Wacky Race, Asa Branca, the song "Peixe Vivo" and the Children's Day coupon.

Listening to the players, kids included

The interactive tutorial spec begins like this: "Users' children played and simply said they 'didn't understand the game'." There is no more honest criticism than a child's.

The tutorial went through four specs in one week. First, it became a real 4×4 board to practice on. Then it got a "What's the goal?" page, showing that the 2048 tile is the Legendary Capybara. Next, the free step started requiring you to reach the Marmoset (32). And finally, the most revealing detail: in the tutorial, tapping a tile swapped its image, which taught that "the animal changes", when what players needed to learn was that "two tiles merge". We replaced it with real swiping.

That is something no well-written spec would have foreseen. The process from the previous post ensures that what was asked for is built right, but only listening to the players ensures that what was asked for is the right thing.

Publishing is half the work

Google Play was relatively smooth. Apple, not so much. In July alone, after the first version on the App Store, came:

• the layout breaking on iPad;

• the mandatory date of birth, considered improper data collection (Guideline 5.1.1), which was replaced with a simple "Are you over 13? Yes/No";

• three rejections in a row because of the same "Confirm" button, which looked frozen (I explained the cause in the previous post);

• cancelling Sign in with Apple showing a raw error;

• gift codes, which unlocked paid items outside in-app purchase, which Apple doesn't allow (Guideline 3.1.1).

Each rejection became a spec, a fix and a rule in ios/CLAUDE.md. And, to top it off, the iOS build runs over SSH on a macOS virtual machine that can't even run the simulator, so everything is compiled and uploaded without me ever seeing the app running there. Today, releasing a version means four channels checked separately: GitHub Releases, Google Play, the App Store and TestFlight.

Knowing what to remove is design too

One thing I learned in this project is that removing something is also a design decision, and often the hardest one.

Audio is the best example. It was cut from scope one day and came back the next as a system 100% synthesized in code, without a single audio file in the app. The music was dropped the day after, sound effects grew from 8 to 25 in August, and in September background music came back: "Peixe Vivo", which is in the public domain, in a 16-bit style, with the sounds rewritten in the style of the Super Nintendo and a voice of its own for each of the 14 animals. All generated in Dart at runtime.

The date of birth went away because Apple required it. The gift code was hidden on iOS. And the Wacky Race got a remote switch that lets us pause the event without releasing a new version of the app, and it was used just a few days later. Removing is not failure, it is adjustment.

What I take away from it

Closing the series, here is what Risoleta and I took from these six months:

1. Ideas are born from observation, not from technology. It was a child pointing at a capybara.

2. Collaborating across different fields works. Someone from Law and someone from IT together built a product neither would have built alone.

3. Close the gaps before coding. An LLM fills in what wasn't said with the most likely answer, not with yours.

4. Tests let you go fast. 1,681 commits in six months are only sustainable with 1,500 tests and continuous integration.

5. AI is a team, not magic. It needs context, rules, review and verification. And whoever writes does not approve.

6. Every bug is a potential rule. The CLAUDE.md files are the project's memory.

7. Listen to the user, kids included. The tutorial was redone four times because of them.

8. Knowing what to remove is design too.

I started this project wanting a technical challenge and ended up with a game that teachers recommend in class (in Portuguese) and that my wife plays every week, competing on the leaderboard. As I see it, there is no better result than that.

Olha o Bichim! is free on Google Play and the App Store, with more information at olhaobichim.com.br. If you have questions about the process, about Superpowers, or about how to work with AI agents without losing control of the project, just get in touch.