PtahCast
← Back to blog

Why We Price Per Client, Not Per Seat

Two bar charts comparing per-seat pricing, which rises with team headcount, against per-client pricing, which tracks client engagements while team size can grow freely

Most project management tools price per seat — a fixed cost for every person invited into the tool, whether they're a core team member, a client stakeholder given read access, or a contractor who only needs to check one ticket. It's the default for a reason: it's simple to explain, and it scales revenue with usage in an obvious way. PtahCast's plans don't work that way. Starter, Growth, and Agency are priced around how many clients you're actively delivering for — 3, 10, and 25 — not how many people are logged in. That's an unusual enough choice that it's worth explaining in public rather than leaving prospects to wonder about it quietly before they ask.

What per-seat pricing actually optimizes for

Per-seat pricing charges for something that isn't really the thing being bought. Nobody adopts a PM tool because they want to pay for headcount — they adopt it to run client engagements well. But a per-seat model attaches the bill to a number (people invited) that moves for reasons that have nothing to do with how much value the tool is delivering. Bring in a client stakeholder for visibility, add a QA contractor for two weeks, loop in someone from finance to check budget burn — under per-seat pricing, every one of those is a new line item, regardless of whether that person is doing an hour of work a month or forty.

The predictable result is that per-seat pricing quietly discourages exactly the collaboration a delivery tool should be encouraging. Teams under-invite people to avoid the cost, which means the tool ends up used by fewer people than would actually benefit from visibility into it — the opposite of what a shared source of truth about delivery dates is supposed to be for.

What per-client pricing tracks instead

PtahCast's plans scale with the number of client engagements running through it, not the number of people involved in running them. A team can add a QA contractor, loop in a project sponsor, bring on a new hire mid-engagement, or invite a client into their own white-labeled portal — none of it changes the bill. What does change the bill is taking on an 11th client on a 10-client plan, because that's the point at which the actual unit of value PtahCast is providing — a forecasting engine standing behind one more delivery commitment — has genuinely increased.

That's the core of the reasoning: price should track the thing that's actually growing in value, and for an agency, that's client engagements, not headcount. A ten-person team running six client engagements and a three-person team running six client engagements are both paying for the same thing under this model, because they're both getting the same thing — six forecasts, six accountability logs, six delivery commitments backed by real data. Team size was never the relevant variable.

What this means in practice

An agency evaluating PtahCast can staff a project however it needs to without doing mental math about whether adding one more person to a ticket thread is worth the extra line item. Team composition can flex — contractors rotate in and out, someone covers for a colleague on leave, a client gets read access to their own portal — without any of that becoming a pricing decision. The only number that matters for the bill is the one that was always the actual unit being sold: how many client engagements the agency is running its forecasts for.

Starter, Growth, and Agency scale with client engagements — never with how many people you invite.

Start free 30-day trial

Get new articles by email

One email when we publish something new. No spam, unsubscribe anytime.