Designing Kairos for small studios
One space per client, approvals as real objects, invoices beside the work, and a short list of things we left out on purpose. The thinking behind Kairos.
Kairos is our client collaboration OS for freelancers and small agencies. It started from a plain observation: a client project is scattered across email threads, chat messages, shared drives, a task board and a billing tool, and the person running it spends part of every day reassembling the story.
This post covers the design decisions behind Kairos and, just as important, what we chose not to build.
A client should be able to find the current state of a project without asking anyone.
One shared space per client
The core unit in Kairos is the client space. Everything for a client lives in one place: files, discussions, tasks, approvals, invoices. The client gets a link to that space, not a seat in your internal tools.
We chose this over a project-centric model for a few reasons.
It matches how small studios think. A freelancer says “I need to send something to Acme,” not “I need to open workspace three, project twelve.” Clients are the relationships; projects come and go inside them.
It gives the client one bookmark. Clients do not want to learn your toolchain. They want one address where the latest version of everything is waiting. A single space removes the “which link was it?” email.
It keeps context together. A conversation about a logo makes sense next to the logo file and the invoice for it. Splitting those across tools forces everyone to remember the connections.
Inside the space, the client sees what you choose to share. Internal notes and drafts stay on your side. The boundary is explicit and visible, so you never wonder whether a comment reached the client.
Approvals are objects, not messages
In most client work, the key moment is the approval. The client says yes, and the work can proceed or be billed. Yet approvals usually live in a chat reply that says “looks good!” which nobody can find three weeks later.
In Kairos an approval is a first-class object. You attach it to a deliverable, name what is being approved, and send it to the client. It has a state: pending, approved or changes requested. It records who responded and when, and it freezes the version of the work that was shown.
That last part matters. If the file changes after approval, the approval still points to the version the client saw. Disagreements about “what did we agree to” get a factual answer.
Because approvals are objects, they can do things messages cannot:
- Show a studio-wide view of everything waiting on a client.
- Send a gentle reminder when something has been pending too long.
- Block an invoice from going out until the related milestone is approved, if you want that rule.
- Leave a clean trail for the next person who picks up the project.
Requesting changes is structured too. The client replies on the approval itself, so feedback stays attached to the thing it concerns.
Invoices next to the work
Billing tools and project tools are usually separate products, so invoicing becomes a monthly reconstruction: what did we do, what was approved, what is the amount?
In Kairos, invoices live in the same client space as the work. An invoice can reference the approved deliverables it covers. The client sees the work and the bill together, and questions like “what is this line for?” can be answered by following a link instead of writing an email.
This is not accounting software, and we do not pretend it is. Kairos handles the part where a studio asks a client for money: creating the invoice, sending it, showing its status and recording that it was paid. Tax filings, ledgers and reconciliation stay in the tools built for them. We would rather do the client-facing step well than cover everything poorly.
Why seat pricing
Kairos Studio costs $19 per seat per month. We debated this a lot, because small studios are exactly the customers who feel pricing most.
We considered usage-based pricing and flat tiers. Seats won for three reasons.
It is predictable. A studio owner can calculate their bill in their head. There are no overage surprises when a busy month brings more clients or more files.
It scales with the value. Each person on your team who uses Kairos gets the same benefits, and the price follows the number of people using it.
Clients are free. The people you invite into a client space do not count as seats. This is deliberate. A collaboration tool that charges for the client taxes the exact behavior it wants to encourage, and clients would stop being invited.
Seat pricing has a known weakness: it can discourage adding a part-time collaborator. We watch that closely. If it turns out to block how studios actually work, we will change the model rather than defend it.
What we left out
Saying no was a design activity too. Here is what Kairos deliberately does not do.
- No built-in chat replacement. Discussions live on the work they concern. We did not build a general-purpose messenger, because studios already have one and a second inbox helps nobody.
- No heavy project management. No Gantt charts, resource planning or dependency graphs. Small studios need a list of what is next and who owns it. Tasks stay simple.
- No time tracking by default. Many studios bill by deliverable or retainer. Forcing timers on everyone makes the tool feel like surveillance. This may return as an option, but not as the core.
- No client accounts to manage. Clients get a link and a light sign-in. They should not have to create a profile to approve a logo.
- No sprawling settings. Every option is a decision the user must make. We prefer sensible defaults and a short list of switches that matter.
Each of these is a feature someone will ask for, and some may deserve a place later. The test we apply is whether it helps a small studio keep a client informed and get paid, or whether it just makes the product look more complete.
Design principles we hold to
Three questions come up in nearly every product review:
- Can the client use this without being taught? If it needs onboarding for the client, it is too complicated.
- Does this reduce a message someone would otherwise have to send? The best features remove a “just checking in” email.
- Would a studio of two people use this on a Tuesday? Features built for imaginary large teams make small teams’ lives worse.
We also build Kairos as a template that other teams can adopt and adapt, so the structure has to be clear enough to read and change without a guided tour.
Kairos is available at kairos.kairn.in. If you run a small studio and recognise the scattered-project problem, we would like you to try it, and we would like to hear what you think is missing, and what we should keep leaving out.
