Skip to content
Back to home

Bolona

  • vibe coding
  • AI
  • women's sports

Women's sports among friends

Read all projectPrevious projectNext project

TLDR:

I know you don’t have time to read a whole portfolio, so here’s what matters:

The problem

Overview

Bolona started with a question: why doesn't women's football hold the same emotional place as men's? It's my own product, from a paper sketch to an app in production.

In men's football, rooting is almost always shared: the family together on Sunday, the office pool, the match watched with friends. That shared memory turns a sport into culture. Women's football doesn't have it yet, largely because people don't know the teams or the players.

Bolona exists to build that memory: a prediction game among friends, only for women's football, that teaches about the teams while the group makes its picks.

Why women's football

Women's football still isn't part of the routine of people who love football. Three factors explain why.

  1. Little visibility

    Men's football fans know the line-up by heart. In women's football, many people don't know who plays, where or when.

  2. Little ritual

    There's no reason to watch together. A pool creates one: every match is suddenly worth something inside the group.

  3. Timing

    The 2027 FIFA Women's World Cup takes place in Brazil. The app was designed for the World Cup and validated earlier, in the 2026 Brazilian Women's Série A1.

Where design comes in

Pools already exist: in spreadsheets, in WhatsApp groups, in betting apps. The design work was deciding what this pool should not be, and designing an experience light enough for someone to join a group from a WhatsApp link and make their picks in under a minute.

The project was also a way to test a method: building a real product, end to end, with AI.

The challenge

Three fronts: positioning, the technical build and day-to-day operation.

  1. Not a betting app

    Sports betting dominates football advertising, and Bolona had to be the opposite: no money, no prizes, nobody winning from someone else's loss.

  2. Built by a designer

    I'm not a developer. Databases, authentication, permissions, deploy and push notifications were new territory, and all of it had to work with real users.

  3. Real data, every day

    A pool without up-to-date scores doesn't work. Matches, kick-off times and results had to be right without typing them in by hand every round.

Product decisions

Three decisions defined what Bolona is and, above all, what it isn't.

  1. No money, ever

    The first version had an entry-amount slider and four named tiers. It all came out: database column, component and copy. If there's ever revenue, it will come from curated ads, never from users' losses.

  2. Friends, not a public arena

    Bolona isn't an open social platform: only people in a group can make picks. Keeping picks among people who know each other is one of the safeguards against addictive behavior. Each group has its own ranking, a single owner and a permanent invite link the owner can close or replace.

  3. A quiz with many jobs

    The quiz only opens while the ball is rolling, which gives people a reason to open the app during the match. Everyone's result is visible to the group, one more way to interact. And the questions get people curious about the teams and the players.

Building and research with AI

Starting with a PRD

To bring together the ideas and research I already had, I wrote the PRD with AI. Iterating with Claude, I cut scope where a feature cost more than it was worth and added what the product would need that I hadn't foreseen.

Defining the UI: references

With clear requirements, I ran a benchmark on Interface In Game, a library of game UI screenshots, to define the visual language. The selected screenshots went to Claude, which described each game in a .md along with what I wanted to bring into the product.

From that document, I chose interface by interface.

Figma board with game screenshots used as reference: an achievement screen, a cat-feeding prompt, an inventory item card, and the home and avatar screens of skribbl.io, slither.io and a GeoGuessr tutorial
Part of the reference board, before it became text.

Building with AI

With the PRD and references ready, I moved to Claude Code with one rule: always explain decisions, alternatives and trade-offs, and leave every choice to me. The paper sketches first became a prototype with mock data, to validate the flow before investing in a database.

To use tokens efficiently from the start, I applied a spec before code method:

  • Context files (CLAUDE.md) with the project's fixed rules, so I didn't have to re-explain the stack and business rules every session.
  • Only four living documents: DESIGN.md (visuals and tone), COMPONENTS.md (structure), PLAN.md (scope, decisions and backlog) and STATUS.md (what's real and what's still mock). More documents than that produced conflicting information, so I consolidated.
  • A short plan before every change, with the "how I'll know it worked" criterion written up front.
  • Start small: one table and one permission rule tested before copying the pattern to the others.
  • Test mode vs. build mode: while I tested, Claude only logged findings in the backlog. Building was my call.
  • Automatic guardrails: a script that fails if anyone uses a color outside the design system, instead of relying on memory.

With every version built, I tested the real flow as a user. Many findings became improvements: the missing toast when saving a group name, the dropdown that cut off long lists, and the profile, which had turned into a pile of links with no separation and was reorganized into sections.

Launch and challenges

The launch was an open beta, in the 2026 Brazilian Women's Série A1, with no paid media. The challenges went beyond the screens.

  1. Legally safe

    Since the product handles real people's data, avoiding legal risk shaped security decisions and features I cut, like a chat. It also led to a minimum age of 18 (younger accounts are deleted on the spot, with no data kept), Terms of Use, a Privacy Policy, an offensive-name filter and a way to report.

  2. Low cost

    As a personal project, cost weighed on every technical choice.

  3. Marketing at match pace

    The Instagram had to keep up with each round and invite people to make their picks and take the quiz. To post from anywhere, without a computer, I built a story generator that turns the day's matches into a post, straight from the database.

  4. Scores without a paid API

    Automating results would have meant paying for a sports data API. The alternative was a scraper for the CBF website, built with what I learned in a Python course, that updates scores and kick-off times automatically.

  5. Google's approval

    Getting approval to show the Bolona brand on the Google sign-in screen took a very long time. It's the kind of problem AI can't solve for you.

Experience

Home and picks

The home brings together the group, the live match and the upcoming ones, with picks for the whole round at once. The right winner (or a draw) is worth 3 points; the exact score, 6. Points are always recalculated from the real score, so there are never "ghost points".

Building an avatar

On sign-up, each person builds an illustrated avatar in three carousels (face, hair and color), with art by Pablo Stanley. That way everyone has a face in the group and on the ranking, without sending a photo.

Edit avatar screen: an illustrated character with curly hair on a turquoise background, carousels for Face, Head and Color, and the Update avatar button
The avatar editor, with credit to the artist.

Ranking

The ranking shows points, exact scores and correct results. Tiebreak goes by points, then exact scores; if it's still tied, it's a real tie. I cut the "who picked first" rule from the original plan because it rewarded speed, not knowledge.

Groups can see the ranking by round, a filter over the competition ranking that doesn't reset the running total. On each participant's profile, every round shows the position she held at the end of it.

Group home with points, correct results and exact scores, next to the overall ranking with seven participants
Who's ahead, round by round.

Live quiz

One attempt per match, with questions about the teams on the pitch, drawn from ten verifiable categories, such as history, head-to-head, records, squad and players' careers. There are 20 seconds per question, so there's no time to look it up. Each answer comes with a fun fact and its source, and the final grade, from A+ to D, is visible to the group.

Result

The pilot in numbers

An organic pilot, with no money spent on promotion. The base is small; those who joined made about 20 picks each.

  1. 41

    people signed up during the pilot, all organically.

  2. 51%

    of them made at least one pick, or 21 active users.

  3. 423

    picks, about 20 per active user.

  4. 61

    quizzes taken by 8 people, almost 8 matches each: those who tried the quiz came back.

Results

Beyond the numbers, the pilot left the product ready to grow.

  1. From paper to production

    Bolona is live at bolona.com.br, in beta, with sign-in, a database and real users in the 2026 Brazilian Women's Série A1.

  2. Ready for the World Cup

    The architecture already supports multiple competitions. Turning on the 2027 Women's World Cup is content work (teams, matches and questions), not code.

  3. A brand, not just an app

    An active Instagram, with content generated from the matches themselves, and a clear stance: Bolona is not a betting app.

Key learnings

Owning the whole product, not just the experience, changed the weight of every decision. Usability had to be balanced against legal requirements, cost, and technical limits. The age check, the terms of use, and the semi-automated score updates all came out of that balance.

I didn’t become an expert in databases, permissions, or deployment, but I gained enough familiarity to assess the technical cost of a design decision before proposing it.

On Bolona, I worked as a product designer in the literal sense, caring about what gets built and how it reaches people. And I learned firsthand that usability, even though it’s my specialty, isn’t enough for a product to succeed: it also takes a lot of effort and investment in marketing. But that’s a story for another chapter.