Skip to content

Demos

Demonstration products, labelled honestly.

Standalone products for common client needs, each deployed separately so you can click through a working example before we talk. Live demos run on fictional data; planned ones show only the concept and proposed scope.

Planned
Concept and scope only. Nothing has been built yet.
In development
Being built. Only the features listed as implemented work today.
Live demo
Deployed separately and usable now.
Temporarily unavailable
Built before but offline right now.

Looking for real, shipped work? See the case studies.

Auré home page: the headline “Light, held in gold.” beside a real-time 3D yellow-gold solitaire ring on a near-black background.
Live demoLuxury e-commerce

Auré

A cinematic store for a fictional fine-jewellery house: procedurally modelled pieces you can turn in 3D, exact finish-and-size variants and a calm path to checkout. Running as a public demonstration: checkout is simulated in your browser, no money moves and nothing you enter is saved.

For: Boutique fashion, jewellery and lifestyle brands that want a storefront with the feel of a printed lookbook.

Deployed separately and usable now.

Still planned

  • Real orders, stock holds and payments in a store's own Supabase Postgres database (the transactional engine is built and tested against PostgreSQL, but not connected to the public demo)
  • Razorpay payments in test mode against a real account
  • Staff sign-in with Supabase Auth on a real project
  • Order confirmation emails

Implemented so far

  • Cinematic home with a live 3D ring on desktop and a rendered still on phones and for reduced motion
  • 3D studio on product pages: procedurally modelled pieces rendered in a Web Worker, with turn, zoom and finish controls and a photo fallback without WebGL
  • Collections, catalogue search and filters (also without JavaScript), quick view and exact finish-and-size variants
  • Wishlist and bag kept in this browser, re-priced by the server
  • Simulated checkout (demonstration only): signed, expiring browser-local orders with sandbox success, decline, late-payment and cancel outcomes, then order tracking; no payment provider is contacted
  • Read-only admin console with fictional data: orders, products, inventory, collections, analytics and settings, where every change is refused by the server
  • Content-Security-Policy without eval or third-party origins, keyboard support and reduced-motion support

Technology

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS v4
  • three.js (Web Worker, OffscreenCanvas)
  • React Three Fiber
  • GSAP
  • Motion
  • Zustand
  • React Hook Form + Zod
  • PostgreSQL 18 (tested engine, not used by the demo)
  • Vitest
  • Playwright
Open live demo(opens in a new tab)How it was built: the Auré case studyRequest something similarto Auré
Saffron Table home page: the headline “Taste the coast before the technique” beside a 3D plate of saffron dessert on a dark dining-room background.
Live demoRestaurant website

Saffron Table

A cinematic, appetite-first site for a fictional coastal Indian kitchen: a menu that reads well on a phone, a guided table booking and a staff console. Running as a public demonstration: bookings use fictional availability and nothing you enter is saved.

For: Independent restaurants and cafés that need a fast, mobile-first site for menus, opening hours and reservations.

Deployed separately and usable now.

Still planned

  • Real bookings stored in a restaurant's own Supabase database
  • Confirmation and reminder emails

Implemented so far

  • Cinematic home with an interactive 3D plate on desktop and a photo hero on phones and tablets
  • Menu with search, dietary and allergen filters, dish pages and a quick view
  • Table booking walkthrough on fictional availability (demonstration only, nothing is saved or sent)
  • Manage-a-booking flow using fictional sample references
  • Read-only staff console with fictional bookings, menu, settings and analytics
  • Light and dark themes, keyboard support and reduced-motion support

Technology

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS v4
  • React Three Fiber
  • GSAP
  • Motion
  • Zod
  • Recharts
  • Postgres schema (Supabase-ready)
  • Vitest
  • Playwright
Open live demo(opens in a new tab)How it was built: the Saffron Table case studyRequest something similarto Saffron Table
Serene home page: the headline “Come in from the day.” beside an arched window throwing late-morning light across a limestone wall, with a slider for the light in the studio.
Live demoAppointment booking platform

Serene

A calm booking platform for a fictional wellness studio: real availability from a scheduling engine that understands therapists, rooms, equipment and buffers, self-service changes through a private link, and a staff console. Running as a public demonstration: bookings are simulated in your browser, no one will expect you and nothing you enter is saved.

For: Clinics, wellness studios, salons and consultants who schedule appointments and lose time to back-and-forth messages.

Deployed separately and usable now.

Still planned

  • Real bookings in a studio's own PostgreSQL database (the locked, audited booking and staff functions are built and tested against PostgreSQL, but not connected to the public demo)
  • Staff sign-in on a hosted identity provider, with password reset and two-factor sign-in
  • Email or SMS confirmations and reminders
  • Payments

Implemented so far

  • Daylight homepage whose light follows the studio's real local time, with a static midday scene without JavaScript and for reduced motion
  • Treatment and practitioner discovery with search and filters kept in the URL (also without JavaScript) and a “who can I see for…” matcher
  • Five-step booking: treatment, length, therapist or anyone, day and time, review; availability calculated by the scheduling engine from shifts, breaks, time off, closures, rooms, equipment and preparation buffers
  • Simulated confirmation (demonstration only), then view, move or cancel through a private link, with cut-offs and a move limit
  • Read-only staff console with fictional data generated by the same engine: day and week calendars, appointments, team schedules, time off, treatments, rooms and equipment, reports and settings, where every change is refused by the server
  • Content-Security-Policy without eval or third-party origins, keyboard support, daylight and evening themes and reduced-motion support

Technology

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS v4
  • GSAP
  • Motion
  • Zod
  • PostgreSQL 18 (tested engine, not used by the demo)
  • Vitest
  • Playwright

How it is built

  • One scheduling engine, written twice: pure TypeScript draws the calendar, and PostgreSQL functions decide every write under row locks and exclusion constraints. A parity suite runs both against the same cases.
  • Double bookings are impossible by construction, not by checks: concurrency tests race bookings, staff edits, closures and cancellations on separate database connections.
  • Staff changes that would strand a confirmed appointment are refused with the list of appointments, never cancelled silently; every change is idempotent and written to an append-only audit log.
  • The public demo has no database at all: simulated bookings live in a signed cookie with no personal details, and the console is generated from the same engine and refuses every change on the server.
Open live demo(opens in a new tab)How it was built: the Serene case studyRequest something similarto Serene
Orbit CRM sales home under a “Demo Mode” banner: overdue and today's follow-ups with checkboxes on the left, open, weighted and won pipeline per currency on the right.
Live demoBusiness SaaS dashboard

Orbit CRM

A multi-tenant sales CRM for a fictional team: leads, contacts and companies, a drag-and-drop pipeline, tasks and one honest timeline per record, analytics that explain every figure, and a copilot that cites a record for every fact. Running as a public demonstration: the data is fictional and stays in your browser, nothing is sent anywhere, and the copilot uses offline rules, not an AI model.

For: Small sales and operations teams tracking leads and customers in spreadsheets and chat threads.

Deployed separately and usable now.

Still planned

  • A hosted multi-tenant deployment for a real team (the PostgreSQL schema, row-level security, sessions and invitations are built and tested against PostgreSQL, but not connected to the public demo)
  • Email delivery, password reset, two-factor sign-in and SSO
  • A hosted AI model behind the copilot (the provider adapter is built and tested against a stand-in, not against a real model)
  • Saved reports and forecast refinements

Implemented so far

  • Leads, contacts and companies with search, filters, sorting and pages kept in the URL; lead qualification and conversion into a company, contact and deal
  • A pipeline board with drag and drop by mouse, touch and keyboard, a Move button as the accessible alternative, won and lost with reasons, and totals kept per currency
  • Tasks with due dates in the workspace's time zone, a sales home of follow-ups and deals that need attention, and an in-app inbox
  • One timeline per record that says how each entry was recorded (by Orbit, by a person, or simulated for the demo), with notes, team comments and logged calls, meetings and emails
  • Analytics where every figure states its source, period, denominator and currency rule
  • A copilot that briefs you on a deal or lead, finds stalled deals by named rules, drafts a follow-up and suggests tasks; every fact links to its record and nothing changes until you approve it (offline rules in the public demo)
  • Role preview (owner, admin, sales rep, viewer) and two fictional workspaces, with reset at any time

Technology

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS v4
  • dnd-kit
  • Zod
  • PostgreSQL 18 with row-level security (tested engine, not used by the demo)
  • Anthropic SDK (provider adapter, not used by the demo)
  • Vitest
  • Playwright

How it is built

  • One application, two stores behind one contract: on PostgreSQL every query runs as a least-privileged role under row-level security, with the workspace taken from the session and tenant-aware composite keys; in the public demo the same screens and rules run on an in-browser store, and a parity suite compares the two for every role.
  • Isolation is tested by attack, not assumed: forged workspace ids, record ids, ownership, sessions and idempotency keys across two workspaces, plus revocation, expiry and concurrency tests on real PostgreSQL.
  • Pipeline moves are optimistic in the browser and decided by the database with a version check and an idempotency key, so two people moving one deal never overwrite each other.
  • The copilot reads only what the member may read, builds its answer from those records with deterministic rules, and keeps facts, rule findings and suggestions apart; a model, when one is configured, may only add a labelled interpretation that is checked against the records.
  • The public demo has no database and no AI provider: everything a visitor does stays in their own browser and can be reset.
Open live demo(opens in a new tab)How it was built: the Orbit CRM case studyRequest something similarto Orbit CRM