From a friend's paper notebook to a multi-tenant SaaS
My best friend runs a car-detailing business, The King Shine. Bookings, cash and materials lived on paper and in Excel. I built ShineApp alone, from the data model to the interface, and it now runs his daily operation.
- Role
- Everything: product, backend, frontend, infrastructure
- Stack
- Django, DRF, Next.js, React, TypeScript, PostgreSQL
- Infra
- Vercel + Supabase, zero budget
- Users
- 1 business in production: The King Shine
- Status
- Active development paused
A real business running on paper
A detailing shop juggles bookings, vehicles, services that consume materials, payments, debts and a cash register that has to close every day. The King Shine did all of it on paper and in Excel.
One user, built as a product
I had one real user and no budget. I still designed ShineApp as a product for many businesses: I saw a market in car-service shops, and the goal is to make it commercial.
All of it
Product decisions, data model, API, interface, infrastructure, tests and documentation. I worked with AI coding agents (Claude and Codex) inside written specs and ADRs.
The path of one job through ShineApp
- RequestCustomers ask for a booking or a quote on the public booking page
- QuoteGroup quotes for up to 25 cars, as PDF
- BookingDay, week and month agenda with capacity checks
- Work orderMaterials consumed by recipe, per service
- PaymentCharged on delivery; debts tracked
- Cash closedDaily register with reconciliation
Decisions on a zero budget
Multi-tenant from day one
Why - Every record belongs to a business account, and the backend enforces that boundary in one shared layer. Dedicated tests check that no tenant can read another's data.
Trade-off
More work up front for a product with one customer. It is what makes a second customer possible.
Serverless on a zero budget
Why - Web and API run as Vercel functions, data and files live in Supabase. With no background workers, a GitHub Actions cron calls a maintenance endpoint every 15 minutes, and migrations never run on a cold start.
Trade-off
Cold starts and a slower database. I designed the interface around it. The plan is to move to better infrastructure once ShineApp goes to market.
UX for slow infrastructure
Why - Request deduplication, cancellable requests, skeletons and stale-while-revalidate on the frontend; composite indexes and prefetching on the backend.
Trade-off
More moving parts in the client, in exchange for a UI that feels fast on cheap infrastructure.
A public booking page for every business
Why - Each business gets its own public page where customers ask for a booking or a quote, with their vehicle and preferred day and time. Requests arrive as pending items that the owner turns into a reservation or a quote in one step, and the owner chooses which services the page shows.
Trade-off
It is a public, unauthenticated way into a multi-tenant system: every request is scoped to its business, and nothing reaches the agenda until the owner accepts it.
Roles that hide money
Why - Owners and employees share the agenda and work orders; employees never see financial data.
Trade-off
Permission checks on every financial endpoint and screen.
What is in production
- Drag-and-drop agenda with sector capacity and overlap checks
- Group quotes and PDFs
- Cash register with daily close and reconciliation
- Debts and fixed expenses
- Materials with recipes and open units
- Pricing by vehicle type
- Public booking page per business, with the services the owner chooses to show
- Dashboard, global search, trash and audit log
- WhatsApp automation and stock (built, not used by The King Shine yet)
Where it stands
In production with The King Shine, which uses every module except stock and WhatsApp. Active development is paused for lack of time. The next steps on the roadmap are billing, team invitations and separate staging and production environments.
Accepting Juani's help to build ShineApp was a before and after for The King Shine. Having the money, the schedule and the whole business in one place made the way I work incredibly faster. I highly recommend ShineApp to other people in the trade, and Juani as a developer, who understood my problem and solved it professionally and efficiently.
What I took from it
- Sitting next to the person who uses the tool beats any spec.
- A free tier is a design constraint. Plan for it from the start.
- Tenant isolation is cheap on day one and expensive later.
Let's talk
Software engineer focused on backend: Python, Django and DRF, with React and Next.js on the frontend. I build and maintain production systems with complex business rules and many integrations, and I use AI tools every day without lowering the bar.
- Available now - contractor or full-time
- Fluent English
- Full overlap with US East Coast hours (GMT-3)