Skip to content
Taking on new projects. Send us a brief
Work

Real problems, honest outcomes

We are early, so this is a short list rather than a long one. Each entry says what the client was up against, what we shipped, and what changed, with figures we can stand behind.

Case studies

Systems running in real businesses. Each one, read in full.

Appooppanthaadi homepage: a women-led group on a hillside under the headline “Your turn to go after everyone else”, with ratings and trip counts.
The Appooppanthaadi homepage on a phone.
Appooppanthaadi

Self-serve booking, and an AI that isn’t allowed to guess

A women-led travel company was handling every trip by hand. Now customers book and pay online, and an AI assistant answers from live data, checking every figure first.

What we solved

  • Customers book and pay online themselves
  • Seats released if a payment never completes
  • Every custom enquiry tracked to a 48-hour reply
  • Cancellations with clear options: transfer, credit or refund
  • AI answers checked against live data before they are shown
Read the case study
Dayone recipes screen: four active recipes (butter brioche, butter cookies, chocolate brownie, white bread) with batch output, ingredient lines, version and unit cost in rupees, beside the sidebar for production, stock, distribution and setup.
Order for XYZ Store, confirmed: white bread 400g, 15 pieces, price left blank to use the list price of 41.12, with a note that the customer called ahead and wants delivery before 9am.
Dayone

One system for a bakery’s kitchen, stock, and wholesale round

A bakery was running its kitchen, stock and wholesale orders across Excel sheets. Now one system carries each order through production and dispatch, with nothing typed twice.

What we solved

  • Orders generated from each shop’s standing order
  • Production tracked from plan to finished batch
  • Stock and costs updated from purchase receipts
  • Recipe changes never rewrite past batch costs
  • Every batch traceable when a complaint comes in
Read the case study
How to read them

Told in the order we work. So they can be compared side by side.

01

Diagnose

The problem the client had before we started, in their terms. It comes first because a result means little until you know what it was up against.

02

Design

What we built, listed in plain terms beside the screens it produced. The screenshots come from the running product.

03

Deliver

The facts of delivery and any headline figure, with where it came from. Where there is no measured result yet, the page says so.

What we publish

The rules every entry follows. A short list is only worth reading if it can be checked.

Every figure carries its source

A headline number is printed with where it came from, so you can ask us to show it.

No result we cannot support

A business figure goes up only with its period and baseline. Where we do not have one yet, we say so.

Design work says so

Anything not yet built is labelled a design engagement, with no outcome or delivery facts, because there are none.

Real screens first

Screenshots come from the live product. A drawn sketch only appears where a real capture would publish something private, such as a client’s revenue.

We would rather show work we can talk about in detail than a wall of logos we cannot. Ask us about anything here and you will get the version with the difficult parts left in.

Ask about an engagement
Get started

Tell us what you’re trying to build. We’ll tell you where we’d start.

Bring an idea, a stalled project, or a system that has outgrown itself.

Send us a brief

The problem, what you have tried, and what success looks like. A few lines is enough to start.

What happens next

  1. 01Reply within one business dayFrom one of our engineers.
  2. 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
  3. 03An honest answerWhere we would start, or, if we are not the right team, who might be.