Blink

The business problem

An acquaintance wanted to launch a cleaning company from scratch in the Netherlands — a crowded market full of similar players. He needed a site that could actually do the work from day one: capture quote requests, tell a real customer from a fake one, and track orders — instead of running everything by phone and WhatsApp by hand. My job was to build that product.

The constraints

• From zero, solo, on €500. No existing system to lean on, no team, a tight budget — every hour had to go into shipping the flow, not infrastructure.
• Dutch market, bilingual. NL primary, EN secondary — the UI had to speak both.
• A phone-first audience. Cleaning customers live in WhatsApp; they don't reliably read email.

What I built and why

A Next.js site on Supabase with a real quote-to-order pipeline: a visitor fills out a service request, gets a verification code over WhatsApp, confirms their phone, and an account plus an order are created in one flow. Phone is the primary identity — email is optional — because that's how this audience actually reaches a cleaning business. Behind it is an admin panel over orders (pending → processing → completed → cancelled), with every admin action written to audit_logs. The interface is NL/EN via next-intl.

Technical decisions, with the cost of each

Decision 1 — WhatsApp + phone as the single identity and notification channel, instead of email/SMS.

This was my call. Phone-first meant one channel did double duty: it sends the signup verification code, and then it carries the order lifecycle — so when the client marks a job in progress or finished, the customer gets a WhatsApp message that their place is done. One number, one channel, onboarding and transactional updates both. For a WhatsApp-native audience that ignores email, that's the difference between a customer who stays informed and one who calls to ask "is it done yet?"

The cost: a hard dependency on the WhatsApp Business API — setup, approval, and per-message limits to respect — and phone as a single point of identity, with no email fallback if a number changes. For this audience, worth it.

Decision 2 — Supabase (BaaS) instead of a custom backend.

Solo, €500, a launch product: Postgres, auth, storage, and row-level security out of the box let me ship the entire verified-signup flow without standing up and maintaining my own infrastructure.

The cost: vendor lock-in, and RLS becomes the security boundary — get one policy wrong and data leaks. The schema and auth live inside someone else's platform. For a solo launch on this budget, the right trade.

The result — honestly

• Shipped to production and went live. The WhatsApp verification worked for real — not the dev-simulated stub, the actual flow.
• Zero orders — and not because of the software. The client stalled on the business side (crowded market, renting, and a legal setup he couldn't figure out) and stopped maintaining the site. My side was done and polished, WhatsApp included.
• No metrics. The product never drew real traffic to measure. Straight answer.
• What it shows: I can take a product from nothing to a working, bilingual, phone-verified order pipeline — solo, on a small budget, in production.