Design Studio Software: Stop Losing Money on Unbilled Rounds and Wrong Files

Why project and review software makes or breaks a design studio

Every 40 person studio we have opened the books on runs the same stack: Asana or Monday for tasks, Figma for design files, Frame.io or Vimeo Review for motion, Dropbox or Google Drive for delivered assets, Slack for internal chatter, Gmail for client approvals, Harvest or Toggl for time, Float or Resource Guru for capacity, and a QuickBooks or Xero link for invoicing. Nine tools. None of them agree on what a project is.

The scene that actually costs money goes like this. A packaging client emails your account director on Thursday at 4pm: "Approved, go to print, but can we make the logo slightly bigger." That approval lives in a Gmail thread. The version it refers to is Figma frame v7, but the designer has already moved to v9. The asset that goes to the printer comes out of a Dropbox folder named Final_v4_APPROVED_USE_THIS. Three weeks later the client disputes the print run. Nobody can produce a single record that says: this exact file, at this exact version, was approved by this named person at this timestamp against this scope line. Your studio eats a $14,000 reprint because the approval trail was distributed across four systems that do not talk.

Then there is the quieter leak. In the studios we have worked in, a producer running 30 concurrent projects loses 6 to 9 hours a week to pure reconciliation: reading Figma comments, translating them into Asana subtasks, chasing which round of revisions the client is actually on, checking whether round 3 was in scope or is billable overage. Run that against your own producer salaries. Across three producers in two locations, you are funding roughly a mid-level designer to copy text between browser tabs.

Problem: rounds of revisions are invisible until they have already blown the margin

Your SOW says three rounds. The client is on round six. Nobody noticed until the project closed at 140% of budgeted hours and the finance lead asked why. This happens because "a round" is not a distinct object in any tool you own. Asana has tasks. Figma has comments. Frame.io has versions. None of them know that a round is a bundle of feedback delivered by a named client contact against a named deliverable, and that round four onward is billable at $150 an hour per your contract.

Asana cannot fix this because a round is not a task, it is a state machine across a deliverable: sent, feedback received, revised, resent. You can fake it with custom fields and someone remembering to update them, which is exactly the process that fails at volume. Figma comments cannot fix it because Figma has no concept of your contract. Frame.io versions are close, but Frame.io does not know about the other 60% of your work that is static, print or brand.

A custom build models the round explicitly. Deliverable has many rounds. Each round has a status, a client contact, a sent timestamp, a feedback captured timestamp, and an in_scope boolean derived from the SOW's contracted round count. When a producer sends round four, the system posts to Slack: "Acme Rebrand, logo suite, round 4 of contracted 3. Estimated overage $2,400. Approve billable or absorb?" The account director makes a decision in three seconds instead of discovering it in a post mortem. Every studio we have built this for reports the same thing: the number is not that revisions dropped, it is that the ones that happened got billed.

Problem: client feedback arrives in five channels and none of them are the file

Feedback comes as: a Figma comment, a Slack DM to the designer directly, a marked up PDF over email, a phone call the account director half remembers, and a Zoom screen share where someone said "make it pop." Your designer's job becomes archaeology. On a large rebrand we have watched senior designers lose most of a day a week just assembling what the client actually wants out of five channels of partial signal.

Off-the-shelf tools cannot fix this because each one owns a channel and has no incentive to be the aggregator. Figma will not ingest your email. Slack will not attach a comment to a Figma frame version. The unified inbox does not exist because nobody who sells you one of these tools benefits from you leaving the others.

A custom build gives you one feedback object with a source field, and it attaches to a specific asset version, not to a project. Email in is real: a per project address like acme-rebrand@review.yourstudio.com pipes into the system, and this is where AI helps rather than decorates. An LLM pass reads the inbound email or the marked up PDF and extracts structured feedback: which deliverable, which page or frame, what change, whether it reads as an approval, a revision request or a question. It proposes the mapping, a human confirms with one click. On a studio doing 200 client emails a week, that extraction step is worth several hours and, more importantly, it stops the "make the logo bigger" note from dying in one person's inbox. Same pass runs on Zoom or Google Meet transcripts: pull the decisions out of the call, propose them as feedback items, producer confirms.

Problem: nobody knows which file is the approved one

Dropbox and Google Drive are folder systems, not version systems. You get Final_v3, Final_v3_REVISED, Final_v3_REVISED_CLIENT, and a designer working from the wrong one because they grabbed it from Slack. On print or fabrication work this is not an annoyance, it is a five figure liability. Studios we have worked with in packaging and environmental design lose more money to this single failure than to any other operational problem.

Figma's version history covers Figma files only, which is maybe half your output. Dropbox's version history covers bytes but knows nothing about approval state. Frame.io is genuinely good at this for video and has been pushing into stills, but it does not know your project structure, your rounds or your contract, and you still end up reconciling it against Asana.

A custom build makes the asset its own record with immutable versions, and approval is a signed event on a version, not a folder name. Approve creates a record: version_id, approver name and email, timestamp, IP, the scope line it satisfies, and a frozen PDF proof. Production files are pulled by the system, never by a human browsing a folder. The release step checks: is this version approved, is the approver authorized on this account, does it satisfy an open deliverable. If not, it blocks. Integrations matter here: Figma REST API to pull frame versions automatically, Adobe Creative Cloud Libraries or a watched folder for the InDesign and Illustrator side, S3 for the actual bytes with lifecycle rules so your storage bill does not quietly become $900 a month.

Problem: resourcing is a spreadsheet that is wrong by Wednesday

Float and Resource Guru cost $6 to $12 per person per month and they do one thing: show who is booked. They do not know that Priya is 80% through a rebrand that is running 30% over, that the client just triggered round five, and that the pitch she is booked on next Monday now has no senior designer. The producer finds out Wednesday when the plan is already broken.

The reason no off-the-shelf resourcing tool fixes this is that the signal lives in the project data, not the calendar. Float only knows what a human typed into it. It is a display of intentions, not a model of reality.

A custom build derives capacity from live project state. Hours logged against estimate, open rounds, deliverables not yet approved, and known client behavior. This is the one place a model trained on your own history pays for itself: after 18 months of your studio's data, the system knows that this specific client averages 5.2 rounds against a contracted 3, that their approvals take 9 days not the 2 in your timeline, and that projects in this category run 22% over on senior design hours. So when a producer scopes a similar project, the system flags it before the SOW goes out: "Similar past projects for this account ran 5.2 rounds. Contracted 3. Recommend scoping 5 or adding an overage clause." That is a margin conversation happening at proposal time instead of at invoice time.

Problem: the client portal you do not have is costing you the relationship

Right now your client experience is: an email with a Dropbox link, a Figma view link they cannot navigate, and a producer who answers "where are we?" questions by hand. Multi-location studios feel this worst, because a client working with your New York team and your London team gets two different experiences and two different sets of links.

Notion or a Monday guest seat is the usual patch. Both leak: Notion guests can wander, Monday guest seats cost real money at scale and expose your internal structure. Neither gives a marketing director a clean answer to "what am I waiting on and what are you waiting on from me."

A custom build gives each client account a portal with exactly three things: what is with you, what is with them, and the approval button. Every asset shown is the current version. Every approval is signed and logged. Automated nudges are the mundane AI win here: the system knows an asset has sat unapproved for 6 days against a timeline that assumed 2, and it sends the client contact a specific, polite, human sounding note referencing the exact deliverable and the downstream impact on their launch date. Not a generic reminder. Studios consistently tell us this single feature pulls 3 to 5 days out of average approval latency, which compounds directly into throughput.

What this costs and what drives the number

Framed only as what Digital Heroes has seen across 2,000+ delivered projects. A focused first release for a studio, meaning project and deliverable model, rounds, versioned assets with signed approvals, feedback aggregation from email and Figma, and a client portal, typically lands at $60k to $130k and ships in 12 to 16 weeks. A full studio platform adding resourcing, time tracking, forecasting, billing integration, multi-location permissions and a full asset library runs $150k to $400k phased over 6 to 12 months, deliberately phased so you are using release one while release two is being built.

What pushes the number up in this specific category, in rough order of impact. First, deep Figma integration: pulling frame level versions and comment threads reliably through the REST API and keeping them in sync is more work than it looks, budget $12k to $25k for that alone. Second, file handling at scale: if your studio produces 2GB InDesign packages and layered PSDs, thumbnailing, preview generation and storage lifecycle is real engineering, not a checkbox. Third, migrating history: pulling five years of Dropbox and Asana into a clean model is usually $8k to $20k and it is where the timeline slips, because your old data is messier than you think. Fourth, if you work with pharma, financial services or government clients, audit trails and access controls stop being nice and start being contractual, and that adds a phase. Fifth, multi-location: two offices means real permission modelling, not a filter.

What keeps it down: pick one workflow and instrument it perfectly. Studios that try to model every service line they have ever sold in release one always overshoot. Studios that pick their highest volume service and ship that in 14 weeks are live and learning while the other kind are still in workshops.

Build versus buy, and I will take a position

If you run fewer than about 15 concurrent projects with one location and under 20 people, do not build. Asana plus Figma plus Frame.io plus a disciplined producer will hold. The $60k is better spent on business development. Buying tools is the right answer far more often than agencies who sell custom software will admit.

Build when you see these signals, and they are specific. One: a producer whose job is meaningfully reconciliation rather than production, at 6+ hours a week. Two: you have eaten a four figure or five figure loss from an approval or version dispute in the last 18 months and you cannot honestly say it will not recur. Three: you are billing under 60% of the revision rounds you actually deliver, which you can check in an afternoon against your last ten closed projects. Four: two or more locations running visibly different processes, so your gross margin varies by office and nobody can say why. Five: you have a service line that is genuinely yours, a proprietary way of running brand sprints or design systems work, and the off-the-shelf tools force you to describe it as generic tasks. That last one is the strongest signal, because it is the only one that makes the software an asset rather than a cost.

The honest middle path most studios miss: build the thin layer, keep the good tools. Do not rebuild Figma. Do not rebuild Slack. Build the system that owns projects, rounds, versions, approvals and clients, and let it pull from Figma and push to Slack. That is a $60k to $130k build, not a $400k one, and it solves 80% of the bleeding.

How to choose a developer for design studio software

Ask them to model your project structure on a call, before any contract. A developer who has built for studios will ask within five minutes: is a round contractual or informal, can a deliverable be approved partially, who is authorized to approve on the client side, what happens when a client approves then reverses. A developer who has not will start talking about the tech stack. The data model conversation is the whole test.

Ask specifically about the Figma REST API and about large binary handling. Have they pulled frame versions and comment threads in production. What did they do about rate limits. How do they generate previews for a 1.8GB packaged InDesign file without blocking. If the answers are vague, they are going to learn on your budget, and that learning is the $25k.

Ask what they will not build. Anyone who agrees your first release should include resourcing, time, billing, portal and asset library in 14 weeks is either not listening or is planning to bill you for the overrun. The right partner will push back and tell you what to cut.

Get code ownership and the exit in writing, in the contract, not in an email. You own the repository, the infrastructure runs in your cloud account, the data is exportable in a documented format from day one, and there is a written handover path if you take it in house or move to another partner. Studios that skip this end up renting their own operations back from their developer, and by the time they notice, migration is a $40k problem.