Pumcha · Antonio Lozano

Pumcha club finances with income, expenses, net balance and transactions — Four nights, one aggregate. The three numbers a club owner asks for at the end of a month, with no spreadsheet in between.

The problem

Nothing was lost. It was just in five places, and no two of them agreed.

I talked to people running clubs in Madrid and the answer was the same every time. Booking details in WhatsApp. Contracts in email. Transport in a spreadsheet. What was actually paid, in someone’s head.

None of that is a filing problem. It is that the numbers never close. A night can look good and lose money, and nobody finds out for weeks because the fee, the flights and the bar take are in three documents nobody joins up. Every handover loses half the context.

If the information lives everywhere, it lives nowhere.

The line I wrote before building anything. Every decision after it had to agree with it.

What it does

One system, from the first booking to the payout

Ten modules, built to reference each other. An artist on a night carries their fee into that night’s result. A document attaches to both the artist and the event. Nothing has to be typed twice, which is the only reason the numbers stay true.

EventsEvery night on a shared calendar, with artists, promoters and slots attached.

FinancesIncome and expenses per event, payouts, invoices, and export at month end.

ArtistsOne roster across clubs, with riders, documents and booking status.

PromotersWho brought the crowd, night after night, and what they were paid.

Guest listsFree and discounted entry with custom fields, checked in at the door.

LogisticsRun sheets built from the event, with contacts, travel and ground transport.

TasksReusable templates for everything that has to happen before doors.

FilesFlyers, riders, contracts and video, attached to the night that produced them.

Multi-clubSeveral venues on one account, sharing artists and promoters.

PermissionsEditable roles, so the door staff and the owner do not see the same screen.

01 / Money

What the night made, while the night is still on

Fees, supplier costs, bar and ticket income all post against the event that caused them. The result is a per-night profit and loss that is right because it was never assembled by hand.

Per eventA live balance, broken down by category, on the same screen as the event.

Per artistFee, booking fee and supplier cost, each with a paid or unpaid status.

Per seasonEverything aggregated across the year, exportable to CSV and PDF.

Balance for one night with income and expense breakdown — **One night.** The balance is the headline, the two bars are what made it, and every line under them is a real transaction.

02 / Talent

The lineup is the schedule, and the schedule is the cost

An artist added to a night brings their fee, their travel and their accommodation with them, and those roll straight into the event total. The same lineup becomes the run sheet the team works from on the door.

CostsFee, flights and hotel per artist, totalled into the night without re-entry.

ScheduleSet times and back-to-back slots on a timeline, saved as they are dragged.

Three artists with fee and travel cost, and a total for each — **Cost per artist.** Fee and flight sit on the artist, and the total on the right is what reaches the night. Nothing here is typed twice.

Lineup timeline with set times and a back-to-back slot — **The night on a timeline.** Set lengths are read from the shape, not from a table of times. The middle slot is two artists back to back.

03 / Files

Every file the night produced, on the night

Flyers, riders, contracts, photos and the aftermovie all attach to the event that produced them. A club does not lose files, it loses the thread between a file and a night, and that is the thing being stored here.

Flyer, rider, aftermovie and poster as tiles — **On the night.** Flyer, rider, aftermovie, print file.

Contract, invoice and payment proof on an artist, with amounts — **On the artist.** Contract, invoice, proof of payment. The amount is read from the cost, never typed again.

The shift

The same jobs, before and after

The product is one argument repeated in every module. Wherever a club was re-typing something, that was the place a number went wrong.

BeforeSpreadsheets and chat

Booking details buried in a thread

The same numbers re-typed across five sheets

Payment status held in someone’s memory

Handovers that lose half the context

AfterPumcha

Artist, cost and document all on the event

One profit and loss per night, exportable

Paid or unpaid, as a flag on the document

A shared workspace with roles and permissions

The build

Chosen so one person could ship a billed product

Every choice here buys the same thing: fewer moving parts to hold in one head. Managed services wherever a managed service exists, and types everywhere, because there is nobody else to catch the mistake.

InterfaceNext.js, TypeScript, Tailwind

DataPostgreSQL on Neon, through Prisma

Accounts and moneyClerk for auth, Stripe for subscriptions

Files and mailCloudflare R2, Resend

RunningVercel

Where it is

In use, and paid for

Two clubs run on Pumcha today and pay for it every month. It is a small number and I would rather give it to you than round it into something vaguer. What it buys is the only test that counts this early: the product has been through a real season, with real money moving through it. The plan is to put more venues on in September.

What I do not have is a usage curve. Two clubs is too few for anything I measured to mean much, and a figure from that base would not survive the second question. The product is open, so the honest thing is to go and look at it.

pumcha.com is the marketing site. app.pumcha.com is the product.