Design tool for small agencies: The editor-to-viewer test

Two numbers decide this, and neither appears in a feature comparison: How many people in your studio actually move pixels, and how many only look at what those people made. Get that ratio right and the shortlist writes itself. Get it wrong and you buy editing power for three people while eighteen client-side reviewers squint at a PDF someone exported "so you can see it properly".

The articles ranking for this query are organised by category — design, project management, SEO, scheduling, social. That is a reasonable map of the software market and a poor map of a five-person studio's Tuesday. Small agencies rarely fail at the design part. They fail at the seams: The logo that arrives as a JPEG cropped from the client's own website, the feedback round living in one person's inbox, the file the developer built from that turned out to be v2 when the client had approved v3.

So the useful question is not which design tool for small agencies has the longest feature list. It is which seams you are willing to hand-carry, and which ones the tool has to close for you.

Count your editors and your viewers before you shortlist anything

Open your current design tool and list every human who touched it in the last 30 days. Mark each one E if they changed something, V if they only looked or commented. Then add the people you routed around the tool — anyone who received a screenshot, a PDF or a screen-share instead of a link. They are viewers too; they are just viewers you are currently serving by hand.

A worked example, using a three-designer studio with nine live projects:

Three editors. Twenty-one viewers. A ratio of 1:7.

The rule: Once viewers outnumber editors by more than 3:1, decide the tool on what the viewer sees on their first click — link or account, browser or install, mobile or desktop-only. Below 3:1, editor ergonomics decide, because your own hands are the constraint and nobody else is waiting on the file. A two-person studio serving one long-running client sits in the second case. Most agencies with more than five concurrent clients sit in the first, and buy as if they were in the second.

The ratio also tells you where a seat conversation will go. If most of your seats are for people who never open the canvas, you are looking for a tool that treats commenting and viewing as a first-class mode — and you need to read the vendor's own definition of "editor" before you model any cost, because that one word decides the bill.

Six classes of tool, and the job each one leaves on your desk

Names below are examples of a class, not recommendations. Fit depends on your ratio, and terms and prices change — read them on the vendor's own pricing page on the day you decide, not from a listicle dated eighteen months ago.

A tool that owns one column is a tool, not a stack. Most small agencies run three of the six and hand-carry the rest. The decision worth making is which gaps you hand-carry on purpose, because those are the ones you can price into a project instead of absorbing at 11pm.

If you are also weighing scheduling, time tracking and task boards in the same evaluation, split them out — that is a different purchase with different failure modes, and I've written about how to separate them in choosing a design project management tool.

The seven places one website project's visuals actually live

Take a single website build and write down where the visual material sits right now. In most small studios it is spread across seven locations:

• 1. The working canvas file
• 2. Client-supplied raw material — logo files, photography, a brand guide PDF, an old style sheet
• 3. Reference and inspiration screenshots
• 4. Copy, in a doc, a sheet or a CMS
• 5. The feedback trail — comments, emails, a WhatsApp voice note, a marked-up PDF
• 6. Production-ready exports — SVGs, compressed images, favicons, OG images
• 7. The record of what was approved, by whom, on what date

The rule: Count how many of the seven your candidate tool owns end to end. Two of seven is normal and perfectly fine — that is a canvas, and canvases are supposed to be canvases. The mistake is buying one and then being surprised that items 2, 5 and 7 are still living in an inbox.

Item 2 is where small-agency time quietly goes. Nobody bills for the third email asking for the vector version of a logo, and no canvas will collect it for you; that is a separate lane with its own rules, which I've broken down in the four traffic lanes of a client file sharing portal. Item 7 is the one that costs money later, when a client asks in month five why the header looks like that and nobody can produce the approval.

What breaks in a three-person studio, and the early symptom

Every honest tool review should say what goes wrong. In small studios it is rarely a missing feature — it is a dependency on one person or one machine.

The account-owner bus factor. One person's login owns the team, the plugin licences, the font subscriptions and the billing card. Test it directly: Can your second person add a client reviewer and restore a file from two weeks ago without messaging the first person? If not, that is your single point of failure, and no feature comparison will surface it.

The file only one machine opens correctly. Missing fonts, a plugin dependency, a linked asset on somebody's desktop. Early symptom: A colleague exports a PDF "so you can see it properly" rather than sending the link. When that becomes the normal way work moves inside the studio, your collaboration tool has stopped collaborating.

The version the developer built from. Early symptom: "Is this the latest?" asked more than once per project. If your build partner is a viewer in your ratio count, their first click matters as much as the client's.

The client's parallel universe. Feedback arrives as an annotated screenshot attached to an email, which then needs transcribing into the tool by you. Early symptom: You are copying somebody else's notes into comment threads. Count how many minutes that takes in one project and you have a real number to weigh against any migration.

Trial it on one live project and watch five moments

Feature checklists don't discriminate between candidates, because most tools in a class check most of the boxes. One real project does. Run it, and record a number at each of these five moments:

• 1. First client click. From receiving the link to seeing the work: How many steps, and was an account required?
• 2. Second round. How many minutes to produce a side-by-side of v1 and v2 that a non-designer can read?
• 3. The awkward asset. Ask the client for the vector logo. How many messages until the correct file format arrives?
• 4. Developer pickup. Hand the file over. How many questions come back before the first line of code?
• 5. Close-out. Eight weeks after launch, retrieve the approved version and the approval date. How many minutes, and did you have to ask the client?

The rule: Weight moments 1, 4 and 5 above 2 and 3. Moments 2 and 3 involve your own hands and you can compensate with practice or a shortcut. Moments 1, 4 and 5 involve people outside the studio, and you cannot fix those from the keyboard.

Run the trial on a project that is representative rather than easy. A brochure site for a friendly client will make every candidate look fine.

What a switch costs, in hours, before you look at any price

Subscription differences are visible on a pricing page. Migration cost is not, so estimate it yourself with three inputs:

• Reusable components and styles: 15–25 minutes each to rebuild or verify after an import. Imports rarely land clean; the verification is the work.
• Live projects: Roughly 1 hour each to re-share, re-invite reviewers and re-point any links you have already sent clients.
• One-time setup: Brand kit, templates, permissions, naming conventions — half a day for a small studio that already knows what it wants.

For a studio with 60 components and 9 live projects: 60 × 20 minutes = 20 hours, plus 9 hours, plus 4 hours of setup = 33 hours. That is close to a full working week for one person, spread across whatever else that week contained.

Two rules come out of that arithmetic. First, convert the hours into your own hourly rate and compare that figure with the annual seat difference at your actual editor count — you can calculate both, and only one of them is printed on a website. Second, the new tool has to remove a step you perform at least four times per project; a step you hit once per project cannot repay 33 hours in any reasonable timeframe. Switch between projects rather than inside one, and never during a month with a fixed launch date unless the current tool is the thing blocking the launch.

How to read a free tier without guessing

"What's the best free design tool" is the wrong question to ask a stranger, because free tiers differ on three axes that only the vendor can answer. Check all three in the vendor's own terms and plan documentation before you put a paying client's work on a free plan:

• Commercial use. Does the free tier permit paid client work, and does that change once you invite a second person or create a team? The answer lives in the terms of service, not in a comparison table.
• The meaning of "editor". Plans meter editors and commenters differently. Find the vendor's exact definition, then map it onto your editor-to-viewer count from the first section.
• The exit. If you stop paying or exceed a limit, what happens — read-only, locked, or exportable? Ask specifically whether client-facing share links keep working, because those are the ones you have already emailed to people you don't control.

The rule: Treat a free tier as a fit test with a deadline, not as a plan. Decide now what you would do if it changed on the morning of a client presentation. If you have no answer, keep client-facing work on something you pay for and use the free tier for internal exploration. The same three checks apply to free tools outside design — invoicing, storage, scheduling — since the failure pattern is identical.

Where the design tool stops and the client's side begins

Everything above concerns the surface you and your colleagues work on. The seam that costs small agencies most is the one before it: The brief, the assets and the sign-off that have to come from someone with no interest in your software.

That is class six in the table, and it is deliberately a different purchase. cluein.me — the product this blog belongs to — sits in that class: One portal link where clients complete a structured brief, upload files and give approvals without creating an account, and a one-click export of the organised result as a ZIP with a structured JSON and Markdown brief. It does not draw anything. It feeds whatever canvas you chose in the sections above.

The practical point is the boundary, not the product. Draw a line on paper: On the left, what your design tool owns; on the right, what has to arrive from outside. If the same tool is on both sides of that line in your plan, you are probably about to be disappointed by one side of it.

Three questions small studios ask at this point

Do we need a separate review and proofing tool?

Look at your ratio and at moment 5 of the trial. If viewers outnumber editors heavily and you struggled to retrieve the approval record eight weeks later, a review layer is doing a job your canvas isn't. If your canvas already produces a readable version history that a non-designer can navigate, adding a proofing tool adds a login without removing a step.

Is a CRM part of this decision?

No — different layer, different failure mode. A CRM tracks people and deals before a project exists; the tools discussed here handle work after one starts. Evaluate them separately, and be sceptical of any single platform pitched as covering both for a team of four, because the compromises usually land on the side you use daily.

We're starting an agency from scratch. What do we buy first?

One canvas in the class matching your main output, and one place for client material to land. Nothing else, until you have run three projects and can count where the hours went. Buying the full stack before you have a workflow means paying to standardise a process you haven't designed yet.

The case this framework doesn't cover: The studio of one

If you are the only editor, the ratio is undefined and the whole exercise collapses into a different question: Recovery. Every viewer is client-side, every login is yours, and the failure mode is not a seam between people — it is a laptop stolen on a Tuesday with nine clients' work on it.

For a solo operation, choose the tool whose worst day you can survive: Files retrievable from a browser you don't own, a second person who can be granted access within an hour, and an export you have actually tested rather than assumed. The scheduling and capacity side of working alone follows different rules too, which is why I treat it separately in project management for freelance designers.

Run the count this week. Three editors and twenty-one viewers is a different purchase than five editors and six viewers, and until you have the number, every comparison table you read is answering somebody else's question.