Haypartido

A football marketplace brand for players and venues in Cádiz. Goudplevier took it from idea to the app stores: definition, design, build, payments and launch. Live in Cádiz, Spain. haypartido.es

What we didDefinition, design, build, payments, launchWhereCádiz, Spain. Spanish and EnglishSurfacesiOS, Android, web, venue consoleStatusLive. iOS, Android and web

1 · The problem

Two sides of the same empty pitch

A player with no team and a pitch with unsold hours. We wrote both problems down before anything was designed, and the whole product follows from that page.

The two-sided problem: the player with no team, the pitch with empty hours

2 · Players

Find a game, pay for one seat, turn up

User journeys and wireframes first, then the build: one codebase for iOS, Android and the web, every screen the same on each.

The player journey in four screens: find, lineup, pay, turn up

3 · Venues

La Mesa, a desk for the person behind the counter

One diary for every booking, games the app fills for the venue, and a till that explains itself. Four rooms in the venue’s own green: Diary, Games, Caja, Your venue. Every tap does one thing, and the second tap says what happens. Designed for the counter, not the boardroom.

La Mesa, the venue console: today's diary on a laptop and three phone rooms

The diary: a free hour asks three questions, a booking asks three more — The diary. One tap, one thing: sell the hour, write a booking down, close it; collect, move, release.

Games: the lineup drawn on the pitch, the armband, the cancel ceremony — Games. The lineup drawn on the grass; the armband; a cancellation that names the people and the euros first.

The till: payouts in Monday batches, the summary, the counter — The till. One batch per Monday with its statement; what to collect at the counter.

Your venue: a pitch page with the week painter and price bands, and the keys — Your venue. Pitches, hours and price bands set once; keys for co-managers, hosts, observers and the bar tablet.

From the door to the inbox: sign-in, the application on a phone, two of the mails — From the door to the inbox. The venue side keeps its own green, in the app and in the mail it sends.

La Mesa on the phone: eight screens — On the phone. Every room fits a phone, one pitch at a time, rooms as bottom tabs.

4 · The money

One price per head, and it explains itself

Card payments, automatic refunds when a game does not fill, and weekly payouts to the pitch. The rules were written before the code, then built exactly as written.

The money model: price per head, where each euro goes, refunds, Monday payouts

5 · The armband

Why a game with strangers actually happens

A trusted regular wears the armband, receives people and kicks off on time. A product rule first, then the screens and the match chat that carry it.

The armband mechanic: the host who makes the game happen

6 · The product

One product, four doors

Player app, venue console, public storefront and staff console share one engine and one set of rules. Sign-in by phone, payments, email, push, and a pre-launch test plan run on production.

7 · The brand

The top corner

Name, mark, colours, type and voice, built for the audience: loud, direct and near-black. Nothing like this site, which is the point.

La Mesa: the week and the till on two laptops

Production screenshots from the live app. Player names, venues and figures shown are placeholder data.

Read the MVP Delivery Pack

One example of what the engagement left behind, alongside the code, the shipped apps and the test harness. Forty-five pages: requirements, process maps, stories, architecture, data model, API, payments, identity, operations, tests, delivery plan, go-live runbook and decision log.

Flip through Open the PDF

How it was built

The diagrams do the explaining.

Ten figures from the delivery pack: the sell-a-seat swimlane, the container view, the entity model, the book-and-pay sequence, the game state machine, the job timeline, wireframe to shipped screen, the test levels, the seven-week plan and the ship pipeline. Click any of them to see it large, or follow the caption into the pack.

**Sell a seat, as a swimlane.** To-be process from a free hour on the diary to a Monday payout, across venue, player, system and money. Figure 2 · section 4

**Entity model.** The core model with crow's-foot ends: users, grants, venues, pitches, games, bookings, reservations, ledger, payouts. Figure 7 · section 9

**Book and pay.** The seat is held before the charge, the webhook reconciles, and the failure path releases the seat. Figure 8 · section 11

**Wireframe to shipped screen.** Three screens, each with the wireframe, the shipped UI and the annotations that changed between them. Figure 15 · section 15

**Game state machine.** Draft, published, then confirmed or cancelled at the deadline, and completed after kickoff plus duration. Figure 12 · section 11

**Test levels.** Five layers, each with an owner, a trigger and an exit: unit tests, contract lints, the QA harness, browser walks and the owner walking production. Figure 16 · section 16

**Job timeline around one game.** Every scheduled job placed on the clock relative to kickoff, from the warm-up nudge to the MVP ballot closing. Figure 14 · section 14

**The ship pipeline.** One command, and every step refuses to continue on failure: gate, build, deploy the API, then web, then mobile OTA, then verify. Figure 18 · section 18

**Seven-week plan by workstream.** Definition, foundations, product, quality and launch, with the five milestones. Figure 17 · section 17

Want something like this built for you?

Fifteen minutes is enough to tell whether it fits. No deck, no pitch.

Book a 15-min call See pricing