Case study — 2026 · PRODUCT DESIGN & BUILD

3X3 CASTILLO DE SÁDABA

Registering and paying used to be two separate problems. Now they're one action, and the organiser stops chasing people.

My roleDesign and build, end to end
CLIENTMitus Sports
TypeFreelance
YEAREarly April to late May 2026
Case study — 2026 · PRODUCT DESIGN & BUILD

3X3 CASTILLO DE SÁDABA

Registering and paying used to be two separate problems. Now they're one action, and the organiser stops chasing people.

My roleDesign and build, end to end
CLIENTMitus Sports
TypeFreelance
YEAREarly April to late May 2026
Case study — 2026 · PRODUCT DESIGN & BUILD

3X3 CASTILLO DE SÁDABA

Registering and paying used to be two separate problems. Now they're one action, and the organiser stops chasing people.

My roleDesign and build, end to end
CLIENTMitus Sports
TypeFreelance
YEAREarly April to late May 2026
The problem01

A team could sign up without paying. Which meant nobody knew who was actually coming until the last minute.

The tournament had been running on a Google Form. A team filled it in and was registered — but registration and payment were separate steps, so the form told the organiser who was interested, not who was in.

Everything after that was manual. Contact each team. Ask for a bank transfer or Bizum. Wait. Check the bank account. Cross-reference it against the form. Chase whoever hadn't paid. Repeat until the deadline.

Some teams paid in five minutes. Others took thirty. Some had to be chased repeatedly if they wanted to play at all. With around thirty teams, that's thirty separate conversations and a reconciliation that never quite finished.

BEFORE AND AFTER02
Previously

Two systems that never agreed

  1. Team fills in a Google Form
  2. Organiser contacts the team
  3. Team pays by transfer or Bizum — or doesn't
  4. Organiser checks the bank account
  5. Organiser matches the payment to the form entry
  6. Organiser chases whoever is missing

Registered ≠ paid · Reconciliation by hand · Final count unknown until the deadline

With the site

One action

  1. Team picks its category
  2. Team pays through Stripe
  3. Stripe sends its own receipt
  4. The entry lands in the sheet, already paid

No payment, no registration · Nothing to reconcile · The count is live

~30
teams registered
3
categories: Masculino Pro, Femenino Pro, Peñas
0
payments to chase by hand
1
source of true instead of two
THREE DECISIONS03
01

Payment is the registration

The single change everything else follows from. A team that hasn't paid isn't on the list, so the organiser never has to reconcile two systems or decide whether an unpaid entry counts. It also removes the awkward part of the job: chasing friends and neighbours for money.

02

One payment link per category

Stripe Payment Links, one per category, instead of a single checkout with a selector. It meant a team could not pick the wrong category or the wrong price, and it kept the payment logic independent of the line-up: categories can be added or adjusted from the Framer panel without anyone opening the code.

03

A spreadsheet, on purpose

Entries land in a Google Sheet, which for this job is the database. Every participant's details arrive structured and in one place, sortable and filterable, and anyone in the organisation can open it on the day without asking permission or learning a new tool.

HOW IT'S BUILT04

Nothing here came out of a template. Every interface piece was drawn first, then written as its own code component.

From design to component

Drawn in Figma, rebuilt in code

The navigation bar, the countdown to the tournament date, the registration form, the team carousel and the grid background were each designed first and then written as a Framer code component — not assembled from ready-made blocks.

Drawn in Figma, rebuilt in code
STRUCTURE

A tree someone else can read

Frames and stacks named and nested so the file makes sense to whoever opens it next, including me six months later.

A tree someone else can read
PAYMENTS

Stripe links as a setting, not a constant

One Stripe Payment Link per category, each one a field in the component's property panel. Swapping a link or changing a price is typing in a box — no code, no deploy.

Stripe handles the checkout, the card data and the receipt, so no payment details ever touch the site.

Stripe links as a setting, not a constant
DATA

Straight into the organisation's own sheet

Google Apps Script writes each completed registration into a Google Sheet owned by Mitus Sports. The destination is a prop too, so pointing the form somewhere else needs nobody to open the code.

That's the difference between a site someone owns and a site they depend on me for.

Straight into the organisation's own sheet
THE SITE05
THE TOURNAMENT06

Around thirty teams, three categories, one weekend in Sádaba.

WHAT IT ADDED UP TO07

Thirty teams registered and paid without a single message asking anyone for money.

The tournament went ahead with its entries closed and paid, and the organisers spent the run-up organising a tournament instead of reconciling a spreadsheet against a bank account.

For me it was the first time wiring separate platforms into one working flow — a Framer site, a payment provider and a spreadsheet that had to agree with each other, with real money moving between them and a date that couldn't slip. Getting that right end to end, on the first attempt, is the part of this project I'd point to.

It also settled how I think about the tools a project should use. The right stack here wasn't the most capable one; it was the one the client could still operate the day after I stopped working on it.

SCOPE

Design, front-end build, payment setup and data pipeline by me. Tournament organisation, categories and pricing by Mitus Sports.

Next projectBARON ATELIER →
Currently taking on new projects

Let's
work together

© 2026 Alejandro Funes00:00:00