Ship-a-ton 2026: Build Log #5 - What We Built, What We Cut, and What’s Still Missing

When we started thinking about BRBito beyond the Shipaton, one question came up that we had been able to postpone until then: how could the app eventually support itself financially?

We imagined multiple companions, environments, accessories, collections, a store, subscriptions, and even ads. AI tools helped us explore many of those possibilities quickly, but between app store reviews and turning those ideas into features that were actually ready to use, the implementation process took much longer than we expected. With only a few days left before the deadline, we started by deciding what should remain free.

The core break experience had to stay free

Setting up reminders, receiving them, starting a break, and completing it are all part of BRBito’s core experience, and we wanted anyone to be able to do all of that without paying. We didn’t want to build an app that said breaks should be simple and accessible, only to put the main experience behind a paywall. For the model to make sense, we started separating two ideas:

The break itself as the core product, and personalization as an optional extra layer.

That gave us a much clearer direction. Instead of charging people to take more breaks or access BRBito’s basic functionality, we could experiment with something optional: changing how BRBito looks and the space where it accompanies the user. That led to our first experiment: a Halloween pack with three environments and a special companion, Batito. The Calm Room and Classic BRBito would remain available for free.

We still don’t know whether people will want to pay to personalize BRBito, or what they’ll care about most: the environments, the companion, or the combination of both. That’s why we chose a small pack and a one-time purchase. It gives us a way to start answering those questions without building an entire store before we have any evidence.

Subscriptions and ads were left for later. We were interested, for example, in exploring ads that could temporarily unlock additional content, but that idea would require us to think carefully about when those ads should appear and whether they would interrupt an app designed to help people step away.

RevenueCat turned the purchase into a real flow

To manage the pack, we started integrating RevenueCat. On paper, the flow looked simple:

Locked content → paywall → purchase → unlocked content

But the difficult part was everything that could happen between those steps. The purchase screen could be closed before the final confirmation arrived. We also had to handle pending purchases, cancellations, errors, and restorations. BRBito couldn’t unlock content too early, but it also couldn’t treat a valid purchase as if it had been canceled. We had to wait for a valid confirmation before unlocking the pack.

At the same time, we needed to make sure that a temporary lookup failure wouldn’t remove access from someone whose purchase RevenueCat had already confirmed. For that case, we kept the last known access state. We also added Restore Purchases, so someone can recover their purchase if they reinstall the app, switch devices, or encounter the locked content again.

Working through these states helped us see the difference between designing a purchase screen and preparing a purchase that someone can complete, recover, and keep using.

The pack also changed the structure of the interface

In some early versions, the character and environment were built as a single composition. As long as there was only one combination, that worked. But once we added new backgrounds and another companion, every variation would have required rebuilding entire screens. So we started treating the environment, companion, and interface as separate pieces. That lets us combine backgrounds and poses without rebuilding every view from scratch. The amount of personalization we managed to create is still small, but we now have a foundation we can expand later.

Following that same principle of only building what we actually needed, we also decided to keep the technology behind BRBito as simple as possible for now. We don’t need our own server or user accounts, because names, preferences, reminders, and break state are stored directly on the phone. For a few specific needs, we do use external tools:

• Firebase, to understand errors and how the app is being used.
• RevenueCat, to manage purchases and know which premium content is unlocked.

Sharing the process helped us understand it

Over these weeks, we used these Build Logs to share how we chose the idea, what we learned from our first surveys, how we explored BRBito’s identity, and what problems came up during implementation. Publishing the process forced us to explain decisions that could have felt obvious to us internally. Why avoid streaks? Why shouldn’t the companion make people feel guilty? Why leave out features we liked?

Sometimes, while trying to explain a decision, we realized it still wasn’t clear enough. Documenting those changes also helped us look back and see how BRBito had moved from a broad idea to a much more concrete experience. That didn’t replace user research. Our early surveys and conversations helped us understand the problem. Sharing the process helped us explain what we were building and why. We’re still learning what the app feels like in everyday use so we can decide which improvements are worth making in the medium and long term.

What we’re taking away from these six weeks as BerylCode

BerylCode is still a young company, even though the people behind it have spent years working on digital products from different roles and contexts.

From that perspective, these are some of the things we’re taking away from the Shipaton:

• This Shipaton gave us the chance to bring that experience together in one project and go through the entire process as a team: researching a problem, making product decisions, designing, developing, and preparing an app for release.
• It reminded us that knowing how to do the work and making sure that work gets seen are two very different challenges. When you build independently, creating a good product doesn’t guarantee that it will find users or generate revenue. Sharing BRBito while we built it became a way to show how we think and work, and to start connecting with people who might never have discovered BerylCode otherwise.
• We kept strengthening our experience making decisions together under a real deadline, implementing and learning new tools, and trying to bring a product to the stores while also sharing what we were learning along the way.
• AI accelerated the exploration of references, images, copy, and alternatives. But researching, choosing, integrating, testing, and fixing still took time. Being able to explore possibilities quickly didn’t mean those ideas were ready — or even feasible — to ship in the app.
• At the beginning, we imagined more breaks, more personalization, and several monetization options. But to reach this first version, we had to keep what made BRBito recognizable and pause the rest for now: breaks that are easy to take, autonomy to choose, reminders without guilt, and a companion that doesn’t demand attention.
• The Halloween pack will give us our first opportunity to observe whether personalization is interesting to potential users. With this first release, we also want to learn which breaks people use most, which reminders are helpful, and which parts of the experience start to feel repetitive. Analytics can show us some patterns, but understanding those patterns will require talking to people again.

The final stretch

We already went through an initial review attempt, and we’re currently testing BRBito with Friends & Family through a basic version of the app. For now, the app is still only available in testing.

We’re finishing the last visual adjustments and the RevenueCat integration before submitting it again for review on the App Store and Google Play. At the same time, we’re preparing the video and the rest of the materials for our Shipaton submission. There isn’t much time left, and we still need approval from the stores, but we’re hoping to make it.

A huge thank you to everyone who followed these Build Logs, answered our questions, supported our videos and posts, and shared their thoughts with us. Talking through the process out loud helped us make clearer decisions and show some of what happens before an app reaches other people’s hands.

We hope we’ll be able to share the result of this final stretch very soon. And, fingers crossed, we hope BRBito makes it to the stores soon so we can start learning from the people who use it.