Vira

Small events companies usually sell tickets through a third-party platform. The audience becomes the platform's customer, the buying experience is the platform's, and the company has no say over fees, payout timing or what happens at the door. Vira wanted the opposite: its own product bringing together ticketing, door control and, in a second phase, on-site spending. The challenge wasn't building a checkout screen. It was handling other people's money safely from day one: Pix and installment cards, chargebacks, producer payouts on a set schedule, the legally required 40% half-price quota, a seven-day right to withdraw and separate LGPD consent. And doing it in time for the first paid event, on a team of four co-founders where I'm the only one who codes.

The public storefront at viraentretenimento.com.br, on desktop and mobile. Events, dates and sale status come from the system; nothing shows up just because it's written on the page.

• Who holds the money: For tickets, Vira collects and pays the producer out: without holding the money there's no way to cover chargebacks. For on-site spending, balances stay with a licensed institution, never with Vira. Each sale's split is recorded at the moment of charging.
• Fee frozen at sale time: The fee is negotiated per event and recorded on each ticket, like the price. Negotiating a different rate tomorrow never rewrites what someone already paid.
• Pix first: Pix costs a fraction of a card payment. It comes first and pre-selected; cards are still there, in full or up to 12 installments, without the spotlight.
• The law becomes a system rule: The 40% half-price quota and the 60+ quota are calculated automatically for every batch. The fire department's capacity is a hard sales limit. A ticket already used at the door can't be refunded.
• Separate consent: Accepting the terms, getting news and sharing data with sponsors are three separate checkboxes. The third can be declined at no cost.
• Address after purchase: For house parties, the storefront and checkout show only the city. The full address goes on the ticket and in the buyer's email.

The visual system came before the screens and was written as a document, the repository's DESIGN.md, with the tokens that Tailwind and the components consume. The core idea is two surfaces with a defined job: dark is where the system operates, at the gate, the till and the back office, and cream paper is where it reports back, on tickets, receipts and statements. Switching surfaces isn't a theme, it's the interface saying which mode it is in.

• An accent outside the semantic range: Stage magenta appears once per band of the screen, on the main action. It was kept away from green, yellow and red on purpose, because at the gate those colors already mean authorized, warning and denied.
• Pending has its own color: An offline queue isn't an error. Painting it red would make the operator try to fix something that only needs a connection.
• Money has its own typeface: Archivo for signage, Instrument Sans for the interface and IBM Plex Mono in every money cell, with tabular figures and right alignment.
• It looks like equipment: Corners of 4 to 8 px and depth through surface changes and 1 px hairlines, with no soft shadows.
• Light theme isn't dark inverted: It exists for daytime back-office work. Magenta got its own variant for small text, and contrast was validated against WCAG AA in both themes.

The two surfaces, the accent with its four states and the three typographic roles, on the visual system page that lives alongside the repository (in Portuguese).

A set of rules for people working on their feet, in sunlight and in a hurry: 56 px touch targets, solid color on more than 40% of the screen, black over the saturated color and a result never conveyed by color alone (in Portuguese).

Checkout opens in a modal over the storefront, with the system's own checkout page inside. Pix, cards and terms acceptance live in one place, with no duplicated payment code. Closing the modal loses nothing: if you close it mid-Pix and reopen, you're back on the same QR code. To make this safe, the system now refuses to be framed by any other site; only the checkout page accepts the storefront. The buyer account is optional and passwordless: the account is the email, access is by one-time code and lasts 30 days on the device. It groups every CPF bought under that email, like a family, and shows valid tickets and purchase history.

The total including the fee shown up front, three separate consents and Pix pre-selected. Cards split into up to 12 installments, with interest shown by Mercado Pago itself.

Each partner owns an area: operations, sales and finance. The back office was designed so none of them needs me day to day. They create events and ticket batches, publish to the storefront, write the copy, pick the cover and see the result in a live preview before saving. Finance tracks what came in, what went back and payouts per event, with each installment's date calculated in business days and a spreadsheet for reconciliation. Cancelling a ticket refunds through Mercado Pago automatically, with the right rule: on a buyer's withdrawal the fee is kept; if the event is cancelled, the refund is full and the fee comes out of the producer's share.

Door control runs on the staff member's phone. The device opens a shift with an event pass, with no password typed at the line, reads the QR code with the camera and answers in solid color, readable from a meter away. Never color alone: approved shows the name, denied shows the reason, and check asks for the half-price or 60+ document. Every entry is recorded under the shift that scanned it.

The door's three answers. The screen was designed for the light and rush of a line, not an office.

With four co-founders making decisions, the risk was decisions getting lost in WhatsApp threads. I set up a password-protected internal handbook built from the repository itself on every deploy: decisions made and pending, back office and door manuals, business rules and the status of every feature. Journeys are drawn as swimlanes per actor, from buyer to payment gateway, with each step's status: working, in rehearsal or still to build. They come from data files, and CI checks that every step marked as done points to code that exists. The page that says what works can't lie without breaking the build. For people who learn by watching, I generated short videos per partner, with Blender and GSAP, covering each flow.

Swimlane journeys and product status, generated from the same files. The last column says what can already be promised to clients and in marketing.

• Amounts always in integer cents, and balances as the sum of movements in an append-only ledger: corrections are new adjustment entries, never edits to the past.
• The payment gateway sits behind an interface: Mercado Pago (Orders API) went to production without touching any service, and a simulated mode keeps serving the tests.
• I migrated from Vercel to a server in Brazil, with database and app on the same machine, scripted deploys and an external watchdog on GitHub Actions that alerts if the site goes down.
• Project rules became automated gates in CI, and a hook blocks merges with red or pending tests.
• Every action that touches money or tickets is logged under who did it, with an authenticated session; never a typed-in name.

I built Vira with Claude Code as an engineering partner. The split was clear: I define the product, the business rules and what ships or waits; the AI writes, tests and documents, always through pull requests, with CI as the judge. What made it work was turning decisions into things that can be checked: a rule you can verify by reading the code becomes a CI gate, and a partners' decision becomes a handbook entry in the same PR that changes the screen. That way speed didn't cost trust, in a product that handles money.

In six weeks Vira went from first commit to a live ticketing platform on its own domain. Mercado Pago went to production on September 30, and the real-money dry run passed: Pix, full and installment card payments, payment notification and automatic refunds. The first paid event is on sale on the storefront, and my partners publish and track events without going through me. The next steps are in the handbook itself, marked as still to build: door control that keeps working offline, cashless spending inside the event, and pre-filled checkout for account holders.