hunter soares

Busca

Cases, contato e CV

Contact↗
PT

Websites with admin and paymentsWebsites and systems · design and code7 min read

Payment inside the site, and the paid order already in the panel.

Three small businesses in Campinas, Brazil, that now sell and run their day through their own site, with payment inside it

Client
Lara Cozinha, Candieiro and Quebra Coco
Period
April to October 2026
Role
Design, code and launch
Scope
3 live sites with admin
Lara Cozinha, payment from the cart2400×1500Lara Cozinha, a cake shop in Barão Geraldo: the order you build becomes a total, and payment goes out from there by Pix or card. Name and phone are sample data.
2
payments built into the site, by Pix or card: the cake at Lara Cozinha and the consultation at the Candieiro.
3
live sites, each with an admin panel for whoever runs the place, from design to launch.
5
connected apps at the Candieiro: site, panel, member area, shop point of sale and finance.
56
people on the house's registry, 31 of them without email, so the member area opens with four digits.

00 File

Sites Lara Cozinha (laracozinha.com.br) · Terreiro do Candieiro (terreirodocandieiro.com.br) · Quebra Coco (grupoquebracoco.com.br)
Product three public sites, each with an admin panel for whoever runs the place. Two of them take payment inside the site
Role design, code and launch, solo. I wrote the code with Claude Code
Scope 3 live sites, 2 integrated payments, 5 apps at the Candieiro, and the admin panel of each
Validation with the people who use it: the cake shop owner, the house's coordinators and the group
Platform web, mobile first
Tools Figma, Astro, Cloudflare, Firebase, InfinitePay, Claude Code
Period April to October 2026

01 Summary

Problem. All three ran on conversation. The cake shop used a third-party menu and closed orders on WhatsApp. The house booked consultations by message and checked payment against the bank statement. The group needed to update its own schedule without depending on anyone.

Role. I designed and wrote the three sites and their panels, and launched them. I wrote the code with Claude Code, and reviewed it before every release.

The decision. Payment goes into the site, before the conversation. People build the order, pay by Pix (Brazil's instant bank transfer) or card, and only then WhatsApp opens, with the order summary already written.

Result. All 3 sites are live. Lara Cozinha and the Candieiro take payment on the site, and a paid order lands in the panel on its own.

Status. Live and in use. I have no before-and-after sales number: what I measure here is what the system guarantees, not the revenue of whoever sells.


02 Context

These are three businesses in Barão Geraldo, in Campinas, Brazil. Lara Cozinha is a made-to-order cake shop. Terreiro do Candieiro is a religious community house with 56 people on its registry, paid consultations, a small shop and bills to close every month. Quebra Coco is a coco de roda group, a circle dance from Brazil's northeast, that needed its schedule, photos and press in one place it updates itself.

In my product work I design on top of a design system that already exists. Here there was nothing: each site carries its own business's look, and the person who maintains it is the person who sells, not a team.


03 Constraint

Nobody there codes. The cake shop owner changes prices and photos on her own, and the house's coordinators build the schedule on their own. Every panel had to explain itself without a manual.

Zero monthly cost. The Lara Cozinha shop runs on Cloudflare's free plans. The only bill is the domain, about R$ 40 a year. The one service that could turn into a charge on its own, photo storage, got a lock that cuts photos before it bills.

InfinitePay does not sign its payment notice. Anyone who finds the address can post "I paid". The system had to check the payment on its own.

31 of the 56 people at the house have no email. Login by an emailed code would leave most of them out.


04 The problem in numbers

The Lara Cozinha menu was a 216-row spreadsheet, with the same filling repeated five times at five prices.

At the Candieiro, the monthly dues of 48 paying members were checked against the bank statement, one by one.


05 Decisions

D1 · Payment comes before the conversation

At Lara Cozinha, search starts from the occasion: birthday, gender reveal, lactose-free. People build the cake, watch the total change with every choice, and pay by Pix or card through InfinitePay. Decoration, theme and the birthday line are agreed on WhatsApp after payment.

The cake drawn as it is built786×1704The cake drawing changes with every choice: shape, sponge, color and topping. The chosen color becomes the color of the whole site while you build, and the total below follows.

Why: an order that only exists in a chat has no fixed price and no guaranteed date. With payment on the site, the conversation starts with the order already decided.

What I gave up: choosing the decoration on the site. Theme, reference and the written line stay out of the form, so the promise has to show up before the order, not after.

01Search starts from the occasion
02The cart
03Pix or card, through InfinitePay
FlowFrom occasion to payment, on a phone. The capture stops before paying: sample name and phone, no order created.

The "we agree the decoration on WhatsApp" banner sits at the top of the home page, before any product. People who built a cake assumed it would come out exactly as clicked, and found out the rest after paying.

D2 · The server decides who paid

InfinitePay's notice is only a trigger. What decides is a check the server makes with InfinitePay, using the order number. If the amount paid does not match the total stored before the payment link existed, the order does not become paid.

Why: with no signature on the notice, trusting it would hand a free cake to anyone who knew the address.

Measured: I tested it with a forged notice. The order stayed waiting for payment.

Going back in the browser does not create a second order. The cart reopens as "waiting for payment", with the same link and a cancel button.

The orders panel2400×1500A paid order lands in New orders on its own. One tap on the name opens WhatsApp with the summary written. Sample data.

The panel splits what is new, what goes out today and what is unpaid, and the clock moves orders between lists, not a checkbox someone forgets to tick. When an order is paid, the owner's phone gets a notification.

D3 · The time is held while the person pays

At the Candieiro, a consultation is paid when it is booked. People pick the day and time, say who is coming, and that time stays reserved while they pay. The server works out the amount from the service's price, and the screen only shows what will be charged.

01Candieiro, date and time
02Candieiro, who is coming
03Candieiro, paying for the consultation
FlowBooking and paying for a consultation, on the copy with sample data. No real booking appears here.

Why: consultations used to be booked by message and payment checked on the statement. Paying at booking locks the time and confirms payment without anyone opening the statement.

What I gave up: a single Pix-only screen. If the payment service goes down, the Pix key shows up again. Payment never becomes a dead end.

The same payment serves three things at the house: consultations, products and event sign-ups.

D4 · Nothing goes out on its own to members who pay dues

The dues reminder never fires by itself. At 9am the system tells the coordinators how many fall due tomorrow. The list comes ready, with amount and due date worked out, and someone at the house reviews it and sends it. Recurring bills work the same way: the system warns that one is due, and a person says it was paid.

Why: a wrong charge to a member costs more than a late one. The machine does the math and a person signs off.

What I gave up: automatic billing. There is one human step a month left, and nobody gets charged for a month they already paid.

D5 · Four digits instead of a password

Each member's area, on the phone, opens with a four-digit code. The phone number is only used the first time. Whoever forgets changes the code by proving the full phone number on file, and the coordinators get a notice of the change.

Why: 31 of the 56 people have no email, and the house has no SMS. Login by an emailed code would leave more than half of them out.


06 Craft

The house admin panel2400×1500The Candieiro panel opens on the day: consultations for today, an overdue task, upcoming events and the open tasks. Sample data.

The Candieiro is five connected apps: the site with paid booking, the coordinators' panel, the member area on the phone with device notifications, the shop's point of sale at vendas.terreirodocandieiro.com.br, and the finance app. Schedule, registry, rosters, recurring bills and tasks live in the panel.

Quebra Coco, the group site2400×1500The Quebra Coco site. The panel behind it has three tabs: schedule, press and photos.

At Lara Cozinha, the 216 spreadsheet rows became 135 items and 220 prices. Each item exists once, and the same strawberry can be a filling in one cake and an add-on in another. One rule between groups covers all 44 fillings at once: a vegan cake only takes vegan fillings.

Allergens have three states, not two. Without confirmation, the site never says "lactose-free". Only the owner can say it, because she knows the recipe.


07 Result

Three live sites: laracozinha.com.br, terreirodocandieiro.com.br and grupoquebracoco.com.br. Two of them take Pix or card inside the site, and a paid order reaches the panel without anyone typing it in.

The Lara Cozinha shop runs at zero monthly cost, apart from the domain. The Candieiro has 56 people on its registry and five connected apps. The five repositories add up to 487 commits between April and October 2026.

I have no sales number. The owner and the house do the selling, and I did not measure before and after.


08 What I would do differently

I would have built login once, for all five Candieiro apps. Each one solved its own, and in July two of them kept passwords in the page's own code. I fixed both on July 30, but the cause was not having a shared layer.

And I would have merged the stock before it grew. The house's pantry ended up in two places, one in each app, and nothing warns when the two numbers drift apart.


Next case
CPF Seguro
  • design systems✦
  • product design✦
  • fintech✦
  • ai in the process✦
  • multi-brand✦
  • accessibility✦
  • research✦