Client systems shown as industry archetypes, with the business unnamed and every identifying detail redacted; demonstration builds we made uncommissioned; and the internal systems behind them — a double-entry ledger, a CNC production pipeline, an outbound engine. Each case study covers the architecture, the stack and the decisions, and says plainly which of the three it is.
Client · not namedA busy dental practice needed the enquiry captured before the visitor left the page — tagged with the treatment the patient chose, and routed somewhere the practice actually reads. The build pairs a validated intake form with a WhatsApp hand-off that arrives already knowing what the patient asked for, and a dashboard that lays out the follow-up pipeline from first enquiry to treated.
Read the case studyHealthcare · physiotherapy and rehab · screenshot withheld
Someone choosing a neuro-rehab clinician checks qualifications before price. The clinic needed those credentials stated where both a patient and a search engine could verify them — and an intake that reaches the clinic on the channel it already answers.
Read the case study
Client · not namedPlot buyers search corridors and landmarks, not developer names. The developer needed a site that answered locality queries directly, published its inventory in a form search engines can read, and moved an interested buyer towards a site visit or a WhatsApp conversation in one tap.
Read the case studyHealthcare · demonstration build · screenshot withheld
A demonstration build for a dental practice with an in-house diagnostics centre, put together to show the practice what its site could be. The interesting constraint was delivery: the whole thing is a single HTML document with the clinic photography embedded in it, so it runs from any host — or from a USB stick — with nothing to install.
Read the case studyHealthcare · demonstration build · screenshot withheld
Built after the single-file demonstrations, and deliberately not like them. Every clinic-specific fact — name, address, treatments, hours, contact links — sits in one typed module, separate from the fourteen components that render it. Re-pointing the system at a different practice is a data edit, not a rebuild.
Read the case study4 source artifacts · src/ledger/engine.ts — 438 lines
Indian cash businesses already record their day in messages — “आज ₹25,000 cement kharida”. The hard part is not reading that sentence. It is making sure a machine that half-understood it can never write a wrong number into the books.
Read the case study6 source artifacts · orchestrator.py — 1,261 lines
A WPC door design has to exist in every size a customer might order, in four different file formats, each named exactly the way the CNC operator expects. Done by hand it is an afternoon of exacting, error-prone work per design — and a single mistyped size reaches the router as scrapped material.
Read the case study5 source artifacts · scripts/system_orchestrator.py — 204 lines
Most outreach tooling is good at sending and bad at listening, which is how a prospect who answered on Tuesday gets chased again on Thursday. This engine treats the inbox as part of the pipeline: replies come back in, and the sequence for that lead stops.
Read the case study5 source artifacts · src/server.js — 458 lines
Text agents get to think. A voice agent has roughly a second before the silence sounds wrong and the person on the other end says “hello?”. Everything in this build — the model choice, the speech cache, the turn handling — is spending that budget.
Read the case study3 source artifacts · parser.py — 1,222 lines
The statement arrives as a photograph of a page. Somewhere in it are three hundred transactions that a business needs in a spreadsheet — and typing them out is how a Saturday disappears. This pipeline reads the scan and hands back the workbook.
Read the case studyNo outcome figures appear on these pages. SheetFlow publishes a result only once it has been measured against a stated method and confirmed with the client in writing. Where that has not happened, the case study says Not publicly disclosed rather than estimating.
A clinic CRM, a luxury storefront's back office, a developer's site and our own control tower. Each says whose data it is, and none of them shows a result we have not measured.
Client build
Healthcare · dental practice
A clinical operations CRM for a dental practice: every enquiry, the treatment it asked about, the stage it is at and the next appointment, tracked on one page from first enquiry to treated.
The dashboard runs on seeded demonstration data (invented patients, placeholder numbers). Names and numbers were also overwritten and blurred for this capture, and the practice name is redacted.
Four numbers lead the page: total leads, this month, converted and pending follow-up. Below them, leads by stage and by source.
A six-column pipeline from New through Treated to Closed shows the treatment each person asked about, and the upcoming appointments carry their status.
The layout folds to a single column, so the front desk can check the pipeline without a laptop.
Engineering showcase · prototype, not a client engagement
E-commerce · luxury retail storefront and executive CRM
A luxury retail storefront with an executive CRM behind it, built end to end as a full-stack prototype to show what a custom back office can be. It is an engineering showcase, not a client engagement.
Every order, buyer and figure here is generated by the project’s own seed script. Phone numbers are masked and the brand wordmark is redacted.
Total sales, orders, unique buyers and average order value, a twelve-month revenue curve and a breakdown of orders by shipping city.
An order pipeline from pending to delivered: each order moves through Pending, Processing, Shipped and Delivered one click at a time. Privilege codes switch on and off at checkout, and bespoke atelier requests queue alongside, each with a WhatsApp contact.
The CRM reflows into a single column of tiles, charts and tables.
Client build
Real estate · plotted development
A plotted-development site for a developer: the offer, the land itself, and a path from first look to a site-visit request or a WhatsApp enquiry.
Captured from the public site as it renders, with the developer’s name, logo, headline and contact details redacted.
The first screen sets the development against its road and offers two actions: schedule a site visit or view the projects. A book-site-visit button stays in the header and a WhatsApp button in the corner.
A photo gallery, each tile labelled with a buyer reassurance (approvals, planning, location, title), shows buyers the ground before they visit.
Internal tool
Our own control tower
The page we run our own agency from. It says what is running, what is stopped and what waits for a person, and how each line was checked.
Lead data, third-party business names, credential details and file paths were removed before this capture, and the rendered text was scanned for leaks.
A banner states the rule (drafts only, a person reviews and sends) and the tiles count what was saved, what was sent and what is held.
Every automation shows its state, how it was checked (a live probe, a file check or a dated observation) and what happens next.
The audit maps where your enquiries arrive, where they stall, and which steps are worth automating first. No commitment, and you leave with the map either way.
