A compact view of the technologies behind the experience, grouped by the role they play in the product.
01
Interface
Next.js
React
Tailwind CSS
Overview
Bombinhas is a small private app for six adults planning a beach trip together. Before it existed, decisions about the itinerary, food, shopping, accommodation and payments lived in chat. The app turns those conversations into one shared place where the group can plan, vote, record expenses and see what still needs to happen.
What it does
01A daily itinerary with activities and voting for what the group should do.
02Shared expenses with each person's paid amount, expected share and current balance.
03A settlement algorithm planned to reduce the final balance to the smallest practical number of transfers.
04Shopping, meal planning and a checklist of what each person is responsible for bringing.
05Accommodation details and shared costs, with Google Maps links for the house and itinerary locations.
06A mobile-first navigation bar and quick actions designed for 375–430px phones.
Why I built it
The goal was not to build another generic travel dashboard. It was to remove the repeated questions and manual arithmetic that make group trips harder to coordinate.
The app is private to the group for now, with the possibility of making the pattern reusable for other trips after the first real use.
A product before the vacation starts.
The case is currently in specification and construction. The expected value is less time searching old messages, recalculating balances and asking who is bringing or paying for something; real usage and savings have not been measured yet.
How it’s built
01The app uses Next.js App Router, React, TypeScript, Server Actions, Tailwind CSS, shadcn/ui and Zod, with the frontend and backend handled by Next.js.
02The first persistence layer uses Vercel Blob because the initial scope is small and limited to one private trip; a Supabase or Neon migration is planned before wider use as the Blob model approaches its practical limit.
03Participants choose a name and use a four-digit PIN. PINs are hashed, sessions use signed HTTP-only cookies, and the app distinguishes member and admin roles.
04Trip records are split into independent resources instead of one shared JSON file, reducing write conflicts when people vote, add expenses or mark shopping items at the same time.
05Server-side Zod validation and financial tests cover equal splits, cent rounding, custom divisions, balances and debt simplification.
06The deployment target is Vercel, with infrastructure credentials kept in environment variables rather than in the client.
Deliberate limits
The app has not yet been validated by the full group in a real trip.
There is no payment integration, climate integration or WhatsApp/Spreadsheet sync; the app organizes the data but does not move money.
A backup strategy is still to be defined before the app becomes a reusable product.
Personal details are intentionally limited; property-owner CPF and unnecessary contract data are not exposed.
Visit site