What we werehanded, and whatwe handed back.

The problem

A few hundred applications per role, read by whoever had the evening free. No two screeners applied the same bar, strong candidates went cold while they waited three weeks for a first call, and by the time anyone reached the good ones they had already accepted somewhere else. The ATS held the records but none of the judgement — nobody could answer why a particular CV had been passed over.

What we did

n8n orchestrates the whole path. An application lands by webhook or watched inbox; the CV is parsed out of PDF or DOCX into structured fields — roles, tenure, skills, gaps — and scored against a written rubric derived from the job description, not a vibe. The score and the reasoning behind it are written straight back onto the ATS record as a note, so the evidence lives where the recruiter already works.

Candidates who clear the bar are invited to a structured first-round interview with an AI interviewer: a fixed question set generated from the same job description, follow-up probing when an answer is thin, and a transcript with per-competency scoring returned to the ATS. The rubric is fixed and auditable, protected attributes are never inferred, candidates are told plainly that the first round is automated, and no rejection is ever issued by the model alone — a person makes every final call, on a shortlist that arrives with its reasoning attached.

The problem

Travellers were already asking on WhatsApp, because that is where they live. What they got was a wait: an enquiry at midnight, an agent at ten in the morning, a fare check after that, and a quote by lunchtime — by which point a good share had booked elsewhere. Every conversation also started from nothing, so a returning traveller had to re-explain the trip they had discussed the week before.

What we did

An assistant on the WhatsApp Business API that owns the whole first conversation. It reads a request in plain language — and in the language the traveller actually wrote in — checks live availability and fares, assembles an itinerary with real prices rather than a brochure, and keeps the thread's context for days so someone can pick it back up mid-trip-planning without repeating themselves.

It hands over the moment the conversation touches money, a visa, a change fee or anything it is not confident about. The handoff is warm: the human agent opens the thread with the full history, the itinerary drafted so far and the reason it escalated, all already written into the CRM. The bot never takes a payment on its own.

The problem

FunGame needed real people competing against each other in real time — not bots, and not turn-by-turn polling dressed up as live play. That rules out the easy architecture immediately: if the client reports the result, the game is only as honest as the least honest player, and at any real concurrency the polling alone would flatten the database.

What we did

The platform runs on a persistent socket layer with room-based state, so a round is a small isolated world rather than a set of rows everyone is fighting over. The server is authoritative: it holds the game state, resolves every round, and treats the client purely as a renderer and an input device — a tampered client can lie about what it did, never about what happened.

The paths that must not block each other are kept apart. Match state lives in memory close to the round, wallet and settlement go through their own durable path, and history is written behind both, so a surge in play cannot delay a payout and a slow ledger write cannot stall a game. Capacity scales horizontally and is added ahead of a known peak rather than during it, and reconnects rejoin the room in progress instead of dropping the player out of a live round.

The problem

Leads, follow-ups and customer history were spread across spreadsheets, phones and memory. Nothing was shared, nothing was reportable, and a handover between staff meant losing the thread on live deals.

What we did

We mapped the real sales motion before designing a single screen, then built a CRM around it: one lead record with the full history attached, follow-ups that chase the owner rather than waiting to be remembered, and reporting built in instead of exported.

The problem

A quality product presented like a commodity. The brand needed to look worth its price on a phone screen, in a category where everything competes on discount.

What we did

Brand direction, product photography art direction, and the full storefront and checkout designed in Figma — component library, type scale and colour tokens included, so the build could start from the file rather than reinterpret it.

The problem

A new brand with no visual language, needing to launch quickly and look established from the first day rather than the tenth iteration.

What we did

Identity, packaging direction and the full e-commerce experience designed in Figma, with an interactive prototype so the flow could be tested and agreed before any of it was built.