Selected work

Both halves, real builds.

Sites and stores out front; the systems and automations behind them. Every live link on this page opens the real thing — and anything built to win the work, rather than paid for, is labelled a concept build.

01 / Case studies

Four in depth

What the business was actually struggling with, what got built, and where each one honestly stands today.

Salon Malisha — screenshot of the build
01Client engagement

Salon Malisha

Hair, beauty & bridal · Attidiya + Moratuwa

A two-branch salon running on WhatsApp threads and a paper diary — rebuilt as a public site with a full staff operations platform behind it.

The problem
Bookings, customer history and takings lived in messages and notebooks. Nothing joined up: a booking made on the website never became a customer record, prices had to be changed in three places, and every staff member could see everything.
What we built
A public site — booking form, live service prices, moderated reviews — and a staff platform behind it: the diary, a customer database that matches people by normalised mobile number, billing with per-branch bill numbers, an append-only payment ledger with refund modelling, QR checkout, and a reviews moderation queue. Four staff roles, scoped by branch.
Where it stands
Website bookings now arrive in the diary as real customer records. A price typed once in Settings reaches the website, the booking form and the billing pickers within a minute — and issued bills never move, because they carry price snapshots. Role limits are enforced in the database, so a stylist typing an admin URL by hand still sees nothing. Built, verified and deployed — a live engagement, held unlisted while we finish the launch.
  • React
  • Vite (prerendered)
  • Cloudflare Pages
  • Supabase Auth + RLS
  • 5 edge functions
  • Postgres
Visit the live site →
ClaimFlow — screenshot of the build
02Live

ClaimFlow

Trading-card retail · WhatsApp commerce · for HoloCandy Co.

Pokémon and One Piece card sales run as claim-races inside WhatsApp groups. ClaimFlow leaves the group exactly as it was and takes over everything after it.

The problem
A claim sale is a hundred lot photos posted to a group. Buyers reply "claim", and the seller then reconstructs who won what by scrolling back through the thread — before typing out every invoice by hand and chasing payments from memory.
What we built
An admin dashboard for building a sale (bulk photo upload, bulk pricing, quantities), a WhatsApp bridge that posts the lots at a human pace and records claims live, and a public catalogue that updates in realtime. On close it posts a group summary tagging every winner, DMs each buyer an itemised invoice with a reference code, then tracks payment, chases what is unpaid and prints the packing list.
Where it stands
Live, and used for real sales. It understands backup claims and multi-unit claims; anything ambiguous is routed to a review queue instead of being guessed at. The bridge throttles its sends and uses reactions rather than replies. The payments table is already shaped for a payment-gateway webhook.
  • Cloudflare Pages
  • Supabase Postgres + RPCs
  • Realtime
  • Edge function
  • Node WhatsApp bridge
Visit the live site →
03Deployed

Axis CRM

B2B sales & procurement · Sri Lanka

A quote-to-procure CRM for Sri Lankan B2B teams, deployed as a separate isolated instance for every client — their own database, domain, users, secrets and backups.

The problem
Distributors quoting imported goods rebuild the same landed-cost arithmetic in a spreadsheet for every enquiry, then re-key the approved quote into a purchase order. Numbers drift between the two, and when a price is questioned months later nobody can say who changed what.
What we built
Pipeline and contacts; configurable LKR/USD quotation with landed-cost logic and approvals; vendor purchase-order generation with PDF output and email dispatch; approved-quote-through-to-delivery order tracking; payroll operations; calendar; a CRM-linked email inbox; and a knowledge-grounded assistant scoped to the team. Thirty tables, row-level security on every one of them, and an append-only audit log.
Where it stands
Deployed, with a searchable in-app help centre and contextual workflow hints on every route. One Supabase project, one domain and one set of Auth users per client — related operating companies can share a single instance while keeping company-level data boundaries. Unrelated clients never share a database, by design.
  • React
  • TypeScript (strict)
  • Vite
  • Supabase RLS + edge functions
  • Vercel
  • Playwright e2e
SDS Spices — screenshot of the build
04Client engagement

SDS Spices

Spice growing, processing & export · B2B

A Sri Lankan spice exporter whose entire website was invisible to the search engines its overseas buyers use. Diagnosed first, then rebuilt server-rendered.

The problem
The existing site renders all of its content in the browser, behind a full-screen preloader. A crawler gets an empty shell — across every route there was effectively no head-level SEO at all. For an exporter whose buyers are searching from abroad, that is the whole marketing channel, closed.
What we built
A server-rendered rebuild: Next.js App Router with React Server Components, strict TypeScript, self-hosted fonts, genuine per-route metadata, and a request-for-quote form gated by Cloudflare Turnstile with server-side verification. Content moves to a Supabase-backed CMS, and the legacy media archive plus the redirect map are tooled for migration.
Where it stands
A paid engagement, currently in build. The rebuild runs on Cloudflare Workers via OpenNext with a KV incremental cache, and the client's production site stays untouched until cutover. At that moment the redirect map carries the entire SEO risk, which is exactly why it is tooled and reviewed before anything moves.
  • Next.js (RSC)
  • TypeScript
  • Tailwind v4
  • Supabase CMS
  • Cloudflare Workers (OpenNext)
  • Turnstile
02 / Websites & Stores

More sites & storefronts

Storefronts, portfolios and product pages — each one built for how that business actually sells, not for a template.

03 / AI Systems & Automation

The systems we run ourselves

The studio runs on its own tooling. These are internal — no client data — but they are the same parts we assemble for client automations.

Internal system

Control Panel / CMS

An operations cockpit: semantic search across every document, transcript and note the studio has produced, a Telegram assistant on top of it, push notifications and automated daily briefs.

  • Supabase + vector search
  • Cloudflare Pages behind Access
  • Telegram bot
  • Scheduled briefs
Internal system

Publishing pipeline

A control panel for the studio's posting workflow — ideas move through queued, drafted and posted, backed by the same database as the cockpit. Installable as a phone app.

  • Cloudflare Pages + Functions
  • Supabase-backed
  • Installable PWA
Internal system

Prospecting pipeline

Scripted lead discovery against a written ideal-customer profile — find candidates, enrich them, and route what survives into a prioritised call list rather than a spreadsheet graveyard.

  • Python + ScrapeGraphAI
  • Scored against a written ICP
  • CSV call lists

Want something like one of these?

Point at the one that’s closest to what you need — we’ll take it from there.