Work we can explain in detail
Every case study below states what the problem actually was, the decision that resolved it, and what we would do differently. Products we own, platforms we build for others, and the occasional small tool that replaced a spreadsheet.
- SECTORS
- Healthcare, education, fintech, enterprise
- MARKETS
- India, USA, Australia, Europe, Dubai
- TOOLING
- Claude Code, daily, across the team
- OPEN SOURCE
- Three products, MIT licensed
Building an AI-first EMR where the doctor decides what the AI sees
A clinician ticks which parts of a record to attach before asking a question. The assistant holds no standing access to patient data.
Read the case study →
Booking a dialysis slot is not booking a doctor
A consultation allocates one scarce thing. A dialysis session needs a machine, a chair, a nurse and a multi-hour block. The engine is built on resources, not calendars.
Read the case study →
A prompt that works is not an automation you can leave running
Version numbers, a sandbox, a release step and a run log. Everything software normally gets, applied to prompts.
Read the case study →
The pharmacy counter is where clinical meets commercial
Upstream it answers to a prescriber. Downstream to an auditor. Built from the prescription outward rather than from the till inward.
Read the case study →
A practice platform built around the tooth chart
Dental history attaches to tooth surfaces, not visits. Get the chart wrong and no amount of scheduling or billing rescues the product.
Read the case study →
An AI clinical reference tool we chose not to launch
Wrapping a language model in a medical app is a weekend of work. Deciding who may ask, and what happens when it is confidently wrong, is the actual problem.
Read the case study →
Feedback that reaches someone while it still matters
Most systems collect and wait for a report. This one notifies the responsible person the moment a patient submits.
Read the case study →
When a chat room can hold an email, a document and a calendar entry
Most collaboration suites are a bundle with one login. Tagging makes the conversation the place the work lives.
Read the case study →
The agent trains for a week. The customer has thirty seconds.
Density is a feature on one side of a contact centre and a defect on the other. Two audiences, two rulebooks.
Read the case study →
A ticket that knows which rack the broken device is in
For a managed services provider a ticket is not a question. It is a device, in a room, under a contract, with a clock running.
Read the case study →
Permission models don’t fail in the model. They fail in the form.
Defining a role is rare. Adding a person is constant. Attach roles to teams and the frequent task needs no decision at all.
Read the case study →
Shipping primitives instead of reports
Every fixed dashboard is a guess. Five display shapes, fixed sizing, movable position — constraint as a kindness to non-designers.
Read the case study →
Configuring what happens on a call nobody has made yet
When the consequence of a setting is invisible until it affects someone real, the interface has to carry what the feedback loop cannot.
Read the case study →
GegoK12: an MIT-licensed school ERP schools can actually own
Schools fear vendor lock-in. An open licence removes the argument entirely — and the commercial model sits above the free core.
Read the case study →
ChurchCMS: built for whoever inherits it next year
Church administration is volunteer work, and the volunteer changes. Continuity is the hard requirement, not features.
Read the case study →
Inventory where every unit has an expiry date
A blood bank fails two opposite ways at once. Stock control and donor relationships are the same problem; most software treats them as two.
Read the case study →
We sell a school ERP. We told this client not to buy one.
Short courses, concurrent enrolments, fees owed by parents. Every assumption a School ERP makes gets in the way.
Read the case study →
Turning one trainer’s judgement into an unlimited supply of exam papers
The questions were an inventory. The judgement about combining them was the asset, and it did not scale past one person’s hours.
Read the case study →
A CRM that verifies the lead before an agent picks up the phone
Move verification into the capture layer and leads arrive with KYC evidence attached, instead of agents spending the day collecting documents.
Read the case study →
Crowdfunding where the student promises something back
A campaign is built on a commitment. Evidence of the result is a condition of raising again, so the platform builds a track record on the student’s behalf.
Read the case study →
Giving a savings group a ledger everyone can see
One person keeps the notebook, and that single fact produces every problem these groups have.
Read the case study →
Four hundred guests, and the AI knows which photos are theirs
Guests opt in with a selfie and receive every photograph they appear in. Event-scoped face collections, serverless processing.
Read the case study →
Android Newswire: keeping WordPress, losing the theme
Headless is a trade, not an upgrade. Worth it here because three surfaces read one API — and usually not worth it at all.
Read the case study →
The church that also runs a wedding venue
One more capability, not a second application to log into. Built additively so the base product stays updatable.
Read the case study →
150 churches, one question, one screen
The ministry did not need accounting software. It needed to know which churches had not paid this month.
Read the case study →Nothing in that category yet.
Six of these are one engagement
The Enterprise UX case studies describe different modules of a single platform built for an Australian managed services provider — collaboration, contact centre, service desk, permissions, dashboards and call routing. We design and build the interface layer; the backend and product direction are theirs.
Not every project needs a case study
Three more places our work lives.
From idea to something people can actually use
Founders who need a working product before the next conversation with a customer or an investor. Scoped tight, built fast, honest about what gets left out of version one.
See MVP work → WEBSITES32+ WordPress sites, built and still maintained
Building a site is the easy half. These are sites we keep running — updates, security, performance and content changes — which is a different commitment from handing over a login and moving on.
See website portfolio → TEMPLATES40+ HTML templates for schools, churches and fintech
Ready-built front-end templates for the three sectors we work in most. Useful when a full design engagement is more than the project needs.
Browse templates →Something here look like your problem?
Tell us what you are trying to build and what is making it difficult. If an existing product would serve you better than something custom, we will say so — several of these case studies are about exactly that conversation.
Start a conversation