Case studies

Real problems, technical decisions and the result that stayed after delivery.

22/22

Jet ski rentals from listing to payout, in production.

Context: A two-sided marketplace: on one side people with an idle jet ski, on the other people who want a day on the water. Three applications, web, iPhone and Android, over a single backend.
Constraint: The money path allows no rehearsal: value is split between platform and owner, a deposit is held on the card before pickup, and refunds happen when a booking falls through.
Technical decision: Stripe Connect with destination charges and an application fee, off-session deposits and transfer reversal on cancellation. The backend is Java in a hexagonal architecture, and both the Next BFF and the Expo app consume the same contract.
Result: The full journey was executed end to end against the live API, payment and refund included, and the measured ruler from push to code in production is fourteen minutes.

2 products

The wallet is charged before the message leaves.

Context: A send-and-receive layer between the products and the official Meta API, with a dedicated number and brand per customer.
Constraint: Meta charges per conversation. A queue that retries without control does not produce an ugly log, it produces an invoice, and a duplicate message to the end customer cannot be undone.
Technical decision: The customer wallet is charged before the send, with idempotency by key and a dead-letter queue for what genuinely fails. Fastify and BullMQ over Redis, with a dedicated console in Next.
Result: Two products in production consume the hub by API key, each keeping its own brand in the conversation with the end customer.

no sign-up

The price that pays the owner’s hour, worked out without an account.

Context: A financial compass for sole traders and small businesses: the arithmetic of what is actually left, redone on its own when materials go up.
Constraint: A diagnosis that asks for an email before showing the number is not a diagnosis, it is lead capture, and asking for revenue from someone who does not trust the product yet is asking too early.
Technical decision: The same cost functions that run inside the product were taken to the browser. The public calculator has no server, no account and stores nothing. Next over Turso, with a security policy generated per request.
Result: Visitors see their own number before deciding whether they want an account.

Anonymised case

39 skills

The report refuses to print outside the rule.

Context: A functional assessment of children’s communication, used in practice and delivered as a report for the family to read.
Constraint: A clinical report admits no single score, no empty bar and no number nobody measured, and there are authorship phrases that must never reach print.
Technical decision: The instrument is versioned data, not code: one definition feeds the Rust API, the front end and the tests. A vocabulary guard runs in the capture phase of the click and cancels printing when the text breaks the rule.
Result: In real clinical use, with an audit trail that prevents deleting an assessment that already has history.

60 Hz

The server decides, the browser only draws.

Context: A 2D multiplayer football game that runs in the browser, with quick matches, offline training and a duel ladder.
Constraint: In a competitive game, a client that computes is a client that cheats, and the same code has to run offline, with no server at all.
Technical decision: The simulation is deterministic and lives in its own package, separate from rendering. The server runs it and broadcasts state, and the client merely interpolates. Offline mode runs that same simulation inside the browser.
Result: Live, with online matches, training without an account and duels, with one single source for game logic, proven by both modes at once.