Per-Seat vs Flat Fee: The Hidden Tax of Agency Tools That Bill by Headcount

The line item I learned to dread on the P&L of the agency I was CTO of was "operations stack". For a long stretch in 2022 it was the fastest-growing line on the agency's cost side, and it was growing for a reason that had nothing to do with us using more tools — it was growing because we were hiring.

Every new hire bought us a marginal cost on each of the dozen tools we ran. Jira: £8. Confluence: £6. Slack: £8. Figma: £15. The CRM: £45. The time tracking: £10. The accounting layer that read it: £20. And so on, down a list that aggregated to about £180 per person per month before we'd added anything bespoke. By the time we hit 100 people we were paying £18,000 a month — £216,000 a year — for an operations stack we didn't actively choose to scale at that pace.

The problem isn't the tools individually. Most of them are fairly priced for what they do. The problem is structural. Per-seat pricing punishes the agency that uses its tools well, and rewards the agency that hoards seats — exactly the opposite of what good operations look like.

This is the article I wish I'd read before signing the renewals in 2022. The math is straightforward. The conclusion isn't comfortable.

The math at 50, 100 and 200 seats

Take the operations stack a typical agency runs. The numbers below are based on real list-price data we collected in early 2026 for a basket of tools any agency would recognise. Real prices on each tool vary slightly by tier and contract; the aggregate has been stable for two years.

Per-seat monthly cost (full editor / pro tier, not viewer):

• Jira Software Cloud: £6
• Confluence Cloud: £4
• Slack Business+: £8
• Figma Professional: £12
• Tempo Timesheets + Cost Tracker: £10
• A project management layer (Asana / ClickUp / Monday Pro): £14
• A CRM seat (HubSpot / Pipedrive Pro): £45
• An identity / SSO seat (Okta / Entra ID): £4
• A monitoring / observability seat: £6
• A design feedback / handoff layer: £8
• A document signing / contract layer: £8

Per-seat aggregate: ~£125/month/person on a "lean" stack, ~£180–220 on a "complete" stack. Some agencies pay more (especially when CRM or analytics seats are at full price) and some less (with consolidated suites and negotiated discounts), but the order of magnitude is stable.

At 50 seats: £6,250–£11,000/month, or £75k–£132k/year. At 100 seats: £12,500–£22,000/month, or £150k–£264k/year. At 200 seats: £25,000–£44,000/month, or £300k–£528k/year.

Now let's add the financial layer that reads margin out of Jira. The dominant tools in this category are mostly per-seat, in the £8–£15/month range. At 50 seats that's £400–£750/month. At 100 it's £800–£1,500/month. At 200 it's £1,600–£3,000/month.

For comparison, Saldo is £2,499/month flat at the Standard tier — every Jira user included. The break-even point against a £15/seat per-user financial tool is around 167 users.

But that "break-even" framing misses the deeper point, which is the next section.

The structural problem: per-seat punishes the agencies that use the tool best

The financial layer specifically — the tool that reads margin out of Jira and tells you which projects are bleeding — has a particular property. It works best when it has access to all of the cost-side data: every named person, every role, every salary, every overhead line. The tool that knows about 80% of your team produces a margin number that's wrong by 20%.

Per-seat pricing creates a perverse incentive: the more people you add to the financial tool, the more you pay. Agencies under pricing pressure routinely respond to this by not adding people to the tool. The operations director gets a seat. The CFO gets a seat. The two senior project managers get seats. The thirty engineers, the eight designers, the four account managers — they don't get seats, because adding all of them would push the financial tool's bill up by £400 per month at £10/seat.

What happens then: the cost-side data is incomplete. Engineers' real hourly costs aren't in the system because nobody is on the engineering tab. Worklogs from named individuals come back unrecognised because that named individual isn't a tool user. Salary changes don't propagate. The tool produces a margin number with caveats and footnotes.

The agency learns to interpret the caveats. By month four, the margin reports are read with mental adjustments — "this number is excluding Sarah's project because she's not in the tool yet" — and the tool slowly degrades from a finance source-of-truth to a finance dashboard with known gaps.

This is not the tool's fault. The tool works fine when fully populated. Per-seat pricing structurally discourages full population. The result is a tool that everybody uses and nobody trusts entirely.

The four cases where per-seat is fairer

Per-seat is the right pricing model for some tools. Three properties make it appropriate:

1. The marginal user genuinely consumes capacity. A heavy user of a video conferencing tool, a CI/CD pipeline, or a content delivery platform is consuming bandwidth, compute, or transactions in proportion to how active they are. Per-seat (or per-active-user) charges roughly track the cost of serving them.
2. The value to the agency scales with the user count. A communications tool like Slack genuinely becomes more valuable as more of the team uses it, in a way that's roughly linear. Per-seat is fair-ish here, because each marginal user adds value the tool can plausibly charge for.
3. The tool is collaborative at the editor level. Figma's per-seat model is fair to designers who actively edit, because Figma's cost of serving each editor is non-trivial.
4. The user count is also the work output. A copywriting agency where every named writer produces invoiceable output, paying per-writer for a writing tool, is roughly fair.

For all four, per-seat is defensible. Outside these cases, per-seat is structurally a tax on growth and a tax on giving the right people access.

A financial layer that reads margin out of Jira does not fit any of the four. The marginal user (a CTO who wants to see role drift) consumes negligible additional capacity. The value to the agency is structurally capped at "everyone with rate data is in the system" — adding the 50th senior CFO doesn't add value beyond the first one. The tool is not collaborative at the editor level. The user count is not the work output.

A flat fee is structurally the right pricing model for this kind of tool.

What flat fee actually changes

The change is mostly about what stops happening, rather than what starts happening. Three things stop:

• The "should we add this person to the tool" conversation goes away. Adding the new finance hire, the part-time advisor, the consulting CFO, the auditor — none of them require a budget approval. They just get added.
• The "we're approaching the seat limit" calendar reminder goes away. Per-seat tools nudge you towards being conservative about access. Flat-fee tools have no equivalent nudge. Access decisions are operational, not financial.
• The data quality stops degrading with growth. Hires get added to the tool on day one, not day fourteen. Salary changes propagate. The tool's data stays current.

What starts happening: the tool's bill becomes a known fixed cost in the operating model. Easier to budget. Easier to compare against the tool's value. Easier to defend in a quarterly review.

What "fair" looks like in practice

We get asked, occasionally, whether flat-fee pricing is fair to small agencies — the implicit worry is that a 30-person agency pays the same as a 200-person agency, which feels regressive.

The answer in our experience: small agencies use flat-fee tools more than they would use per-seat tools, because the marginal cost of access is zero. A 30-person agency on a flat-fee financial layer typically gets every named individual into the system within the first month, where a per-seat agency might only have leadership and a few project leads in for the first quarter. The tool's value-per-pound is therefore higher for the small agency on flat fee than the same tool would be on per-seat.

What flat-fee pricing implies for the vendor: you have to defend the price against the value at every size of customer. A 30-person agency paying £2,499/month has to be getting at least £2,499 of monthly value, which they are if the tool catches even one mid-sized margin leak per quarter. A 200-person agency paying £2,499/month works out to about £12.50 per person per month — roughly at parity with the mid-range per-seat tool, and structurally cheaper than the high end. Above 200 staff, the flat-fee gap widens linearly.

For the agency, flat-fee changes the question from "can we afford to give the next person access" to "is this tool worth its monthly fee, full stop". That's a cleaner question to ask, and a more honest one.

What we do at Saldo

We built Saldo as flat-fee from day one because the math above made the case so cleanly. The Standard tier is £2,499/month flat — every Jira user included — or £23,990 annually (saving £6,000). The Enterprise tier from £5,999/month adds SOC 2, SLA, SSO and multi-language UI, but the per-seat charge stays at zero. Our pricing page lays out the full feature comparison.

The most common pushback we hear in early conversations is that the price looks high relative to per-seat alternatives. The math above is the answer to that: a 100-person agency paying £10/seat for a per-seat alternative is paying £1,000/month, not £100. Saldo at £2,499 is in the same neighbourhood while removing the structural disincentive to give access to the right people.

The rarer pushback we hear, and the one that lands: that the agency is small enough today that per-seat would be cheaper. That's true at 30–60 people on the math alone. The counter-argument is that the small agency is the exact place where giving every named individual cost-side data matters most, because the leak from incomplete data is proportionally larger when each individual represents 2–3% of the team. The flat fee removes the temptation to leave half the team out of the system for cost reasons.

The shorter version

Per-seat pricing has a small headline number and a structural cost. The structural cost is invisible in month one and obvious by month twelve: it's the tax on every operations decision that involves giving the right person the right access. Across a stack of a dozen tools, the tax is large enough to change behaviour. The behaviour change reduces the value of the tools the agency is paying for, which is the worst outcome for everyone except the vendors charging per seat.

Flat fee inverts this. It rewards the agency for using the tool well. For tools where access correlates with value — and a financial layer is the canonical example — flat fee is structurally the right choice.

If you're interested in seeing what the financial layer looks like with every Jira user in the system from day one, Saldo is the version I built around my own agency's needs as its CTO. The 15-minute demo runs on your real Jira data; we don't ask for card details up front; we don't follow up if it doesn't land.