Casework

The brief

Every piece of work a studio wins starts as a name on a list. Ours lived in spreadsheets, inboxes and memory, and the gaps showed: a follow-up missed here, a proposal sent twice there. So we gave ourselves the brief we give clients who have outgrown their tools: build the system the work actually needs, then run the business on it.

Casework had to cover the whole journey, from finding a business to being paid by it. Paste a web address and get a lead. Know what to say before saying it. See every conversation on a board that shows what happens next. And because the studio now has a team, it had to carry the people side too: who is working on what, who is off, and what each person is owed.

What we built

A lead starts as a web address, a CSV of hundreds, or a name typed in by hand. Casework reads the business's website and writes a short dossier: what they do, what their current site gets wrong, whether Google can see it, and which of our services to offer. The research runs through OpenRouter, with the model chosen in the app's settings.

Every lead sits on a kanban pipeline: one for client work, one for agencies and one for contracts. Each card shows how many days since the last touch and when the next step is due. Outreach is drafted from templates with merge fields, for email, text, WhatsApp, social or a phone call, and follow-up sequences schedule what comes next. A demo can be attached to any deal on a tracked link, and the card lights up when the client opens it. Proposals go out as a page with an accept button.

Since version 1.2 it is also where the team works. An owner's dashboard covers money, sales, people, delivery, compliance and an audit trail. Delivery projects have a task board, and there is a team directory, direct messages and a notification inbox. Staff book their own leave, work through assigned training and upload requested documents. Everyone gets a summary email at 8am and 5pm on weekdays, and a shared calendar pulls in leave and deadlines, with a private feed for phone calendars. Three roles, owner, editor and staff, decide who sees and changes what.

The details that mattered

• 01

  It runs on UK time throughout. The servers keep UTC, so every due date, summary and calendar entry is worked out in Europe/London, and a 9am meeting stays at 9am when the clocks change.

• 02

  Nothing is emailed twice. Each summary, invite and notification claims a line in a send log before it goes, so a retried job, or two servers running at once, cannot double up.

• 03

  Private stays private. A person's pay is visible only to them and the owner, a private calendar event only to the people invited, and bank details are encrypted where they are stored.

• 04

  Database changes ship with the code. Every deploy applies its changes in a guarded, repeatable way, so running a deploy twice changes nothing the second time.

• 05

  It installs to a phone's home screen, works one-handed at phone width, and comes in light and dark themes.