The case against per-seat time tracking pricing

Here is how it almost always starts. A six-person team needs to track hours, picks a well-known tool at eight dollars per user per month, and signs up. Forty-eight dollars a month. Nobody blinks — it's less than the team's coffee budget, and the tool works.

Two years later that team is thirty-five people. The same tool, the same features, the same one-click timer — now $280 a month, or closer to $600 if anyone upgraded a tier to unlock the report export they needed. The line item has quietly grown 6x, and not one person on the team can tell you when it crossed $100, because the bill scales automatically with the thing every company is trying to do: hire.

That is the per-seat tax. It isn't a scam and it isn't hidden in the fine print — it's right there on the pricing page as "$X per user per month." What's hidden is the slope. You evaluate the price at the size you are on signup day, and then you index it to a number (headcount) that has almost nothing to do with how much value the tool delivers per person. A timer is a timer whether the company is six people or sixty. The database row a thirty-fifth user generates costs the vendor a fraction of a cent. But you pay for it as if every new hire unlocked a new, more valuable product.

The reason this matters more for time tracking than for, say, your CRM is that everyone on the team needs a seat. A CRM might touch ten of your thirty-five people. A time tracker, by design, touches all of them — that's the entire point. So time tracking is the SaaS category where per-seat pricing compounds the fastest and where the cost of getting the pricing model wrong is the highest.

If per-seat pricing is so punishing for growing teams, why does nearly every tool use it? Because it is an excellent model — for the vendor. It's worth understanding the mechanism, because once you see it you can't unsee it on any pricing page.

Per-seat pricing ties the vendor's revenue to a number that grows on its own. When you hire, they earn more without shipping anything new. Revenue tracks "customer success" (more employees usually means a healthier customer) and it's trivially easy to forecast: a SaaS company can model next year's revenue as "current seats × expansion rate × price." Investors love that curve. It is, genuinely, one of the cleanest business models ever invented.

None of those reasons have anything to do with the value you receive. They're properties of the vendor's income statement, not your usage. This is the mental model to carry into every pricing conversation: per-seat pricing is optimized around the vendor's revenue curve, not your consumption of the product. Your bill is indexed to headcount because headcount is the variable that makes the vendor's spreadsheet work — not because the eleventh user costs them eleven times what the first did, and not because your team gets eleven times the value.

The honest counter is that some usage-linked pricing is fair (we'll get to that), and per-seat is at least legible — you know exactly what next month costs. Fair enough. But legibility isn't the same as alignment. A model can be perfectly predictable and still charge you for the wrong thing. Per-seat is predictable in exactly the way a tax is predictable: you can see it coming, and it still grows every time you do the thing you want to do most.

Abstractions don't change minds; arithmetic does. Let's price a real team. Mainstream trackers land somewhere between $4 and $18 per user per month depending on tier — the cheap end is a stripped feature set, and the features most teams actually want (rich reports, billable rates, locked timesheets, exports) tend to live on the $9–$18 tiers.

Take a 25-person team on a $10/user plan. That's $250/month, or $3,000 a year. Bump to the $18 tier for the reporting you needed all along and it's $450/month — $5,400 a year. For a timer and some reports. For comparison, a flat plan at $29.99/month is $360 a year, full stop. The gap between $3,000 and $360 isn't a rounding error you absorb; it's most of a contractor month, or a chunk of the conference budget, spent on per-seat overhead.

Now add the variable that per-seat pricing punishes: growth. Take that same team from 25 to 60 people over eighteen months — a totally normal trajectory for a company that's working. The per-seat bill goes from $250 to $600 a month (at the cheap tier) or $450 to $1,080 (at the rich tier). The flat bill goes from $29.99 to… $29.99. You added 35 people and your time-tracking cost moved by zero.

The break-even is the number worth memorizing. Against a $29.99 flat plan, a $10/user tool breaks even at three users. Above three people, flat is cheaper — and the advantage widens with every hire. Most teams shopping for a "real" time tracker are well past three people, which means most teams are, today, paying a premium that grows on a schedule they don't control. If you want to see how this plays out against two specific tools, we walk through it on our Toggl vs Clockify comparison and on the Toggl alternative and Clockify alternative pages.

The bill is the obvious cost. The behaviors are the expensive one, and they're the part nobody models on signup day.

Seat rationing. When every seat has a price, someone starts guarding them. The intern doesn't get a login because "they're only here twelve weeks." The two contractors share an account. The new hire waits until the admin does the monthly seat reconciliation. Each of these is a rational micro-decision, and together they punch holes in the exact dataset the tool exists to produce. You bought a time tracker to know where the hours go, and the pricing model just made sure the intern's and the contractors' hours are invisible. The data is now wrong in a way that's hard to see and impossible to back-fill.

Shadow spreadsheets. The people who got rationed out don't stop working — they track time in a spreadsheet, a notes app, or not at all. Now you have two sources of truth, and the reconciliation work (someone copy-pasting a freelancer's hours into the real tool every month) costs more in payroll time than the seat would have cost. You've spent money to create manual work.

Annual true-up surprises. Teams on annual plans hire throughout the year and then get a true-up invoice for all the seats added since the last anniversary. It's a predictable surprise — predictable to the vendor, a surprise to whoever owns the budget.

License audits. Eventually someone notices the bill and runs a "who's actually using this" audit — pulling last-active dates, hunting dormant seats, deciding who to deactivate. That audit is real human hours spent managing the pricing model instead of doing the work. The tool was supposed to save administrative time. Per-seat pricing quietly hands some back.

None of these show up in the per-user number on the pricing page. All of them are downstream of it.

The strongest defense of per-seat pricing deserves a fair hearing, because it's partly right. The argument goes: per-seat aligns price with value. A 200-person enterprise gets far more value from a time tracker than a 5-person shop, so it should pay more. Charging both the same flat fee would mean either overcharging the small team or undercharging the big one. Per-seat is just… fair.

At the extremes, the value gap is real: a five-hundred-person agency gets more out of a time tracker than a two-person studio. The flaw is what the price tracks. Per-seat pricing charges a linear price for what is, to the vendor, a near-zero marginal cost and, to you, a roughly flat marginal value. The tenth person tracking time doesn't make the tool ten times more valuable to your team; they make it marginally more complete. But you're billed as though value scaled in a straight line with headcount, when it actually flattens out fast.

The same arithmetic is why a flat plan doesn't need a user cap. If the tenth user costs the vendor next to nothing, so does the hundredth. Yes, that means the five-hundred-person agency pays what the two-person studio pays. The agency gets more out of the tool, but not 250 times more, and it doesn't cost 250 times more to serve. Flat pricing with no user limit stops taxing every hire, and it removes the pricing conversation a cap still forces: the day you cross it. You pay one price from "small" to "genuinely large," and headcount stops being a line item.

So the case here isn't "per-seat is always wrong." It's "per-seat applies a linear tax to a flat-value, near-zero-marginal-cost product across the exact size range where most teams spend their entire lives."

We sell a flat-priced tracker, so treat this section with appropriate skepticism — and then read it anyway, because switching pricing models on principle instead of on math is how teams talk themselves into a worse deal. There are real cases where per-seat wins.

You're tiny and intend to stay tiny. If you're three people and you have no plan to be more than five, a $6–$8/user tool can cost less than a $29.99 flat plan. Three users at $8 is $24 — cheaper than flat, and you should take it. The break-even math cuts both ways; below it, per-seat is the rational choice. Don't pay a flat price sized for a team you'll never become.

Your headcount is genuinely spiky and your vendor lets you flex. If you staff up to forty for a three-month project and drop back to eight, and the vendor lets you deactivate seats and stop paying for them mid-term (not just at renewal), per-seat can model your real usage better than a flat plan sized for your peak. The catch is in the terms — see the next section — because plenty of vendors offer seat reduction in theory and only at the annual anniversary in practice.

You need genuinely per-user features. Some products attach real per-seat value: individual SSO provisioning, per-user storage, per-user automation runs. If the thing you're buying actually scales per person, per-seat pricing is honest about that. Time tracking, for what it's worth, rarely qualifies — a timer is about as close to identical-per-user as software gets — but the test is sound: if the marginal user consumes real marginal resource, per-seat is defensible.

The throughline: switch on the arithmetic, not the ideology. Run the numbers for your team at your real trajectory, and let the break-even decide.

Before you commit to any tracker, run its pricing page through this checklist. Each item has a thing to check and the red flag that should make you pause.

1. Model 24 months of headcount, not today's. Price the tool at where you'll be in two years, not where you are on signup day. Red flag: the sales quote only shows your current-team cost and goes quiet on the growth curve. They know the slope; make them show it.

2. Find where the per-seat features live. List the three features you're actually buying the tool for, then find which tier they're on. Red flag: the feature you need is one tier up and that tier is also per-seat — that's the double-escalator, where your bill grows on both axes at once.

3. Read the seat-change terms. Find out, in writing, whether you can remove seats mid-term and stop paying immediately. Red flag: an annual commit with seat reductions that only take effect at renewal. That's a peak-headcount bill dressed up as flexible.

4. Price the ceiling, not just the per-unit. If a plan is flat, find the user cap and what's on the other side of it. Red flag: a flat plan with a low cap (say, 10 users) that dumps you into "contact sales" exactly when you start growing. A flat plan whose ceiling you'll hit in a year isn't really flat.

5. Total the cost of the data, not the tool. Ask whether the price makes you ration who gets to track. Red flag: a cheaper per-seat option that you already know will lead you to leave contractors and interns off the system. A tool that's $40 cheaper a month but corrupts your billable dataset is not cheaper.

Run those five and you'll know more about a tool's pricing than most teams learn in their first year of using it. If a flat plan suits a specific shape of team, we've written up the cases for small teams, agencies, and consultants in detail.

If you already pay for a tracker, you can find out today whether the model is working against you. Block thirty minutes and do this in three ten-minute passes. Each pass has a "what done looks like" and a "if you're behind" branch.

Minutes 0–10: chart cost against active users. Pull your last twelve invoices and plot monthly cost beside monthly active-user count. Done looks like: a simple line where you can see the slope of the bill against headcount. If you're behind: if the billing portal hides per-month history, export your card or bank statement and use the charge amounts instead — you only need the trend, not perfect attribution.

Minutes 10–20: compute seat utilization. Count seats you pay for versus seats that logged any time last month. Divide. Done looks like: a single utilization percentage. Under ~70% means you're paying for rationed, dormant, or duplicate seats. If you're behind: ask your admin for the "last active" column or the user export — most tools have one even if it's buried in settings.

Minutes 20–30: project the bill at +50% headcount. Take your current team, add 50%, and price it two ways: under your current per-seat model, and under a flat plan. Done looks like: two numbers and the team size where they cross — your break-even headcount. If you're behind: use the vendor's own pricing-page math; you don't need a quote to multiply users by a published per-seat rate.

The output of all this is one number: the headcount where flat pricing becomes cheaper than what you pay now. Below it, your current model is fine — stay put. Above it, you're paying the per-seat tax, and the gap compounds with every hire. In our experience most small and midsize teams cross that line somewhere between eight and fifteen people, which is to say: right about when they start thinking of themselves as a real company.

If the audit pushes you toward flat pricing, don't just swap one trap for another. "Flat" can hide its own problems — a low user ceiling, a stripped feature set, a per-seat add-on maze bolted onto a flat base. Three things to demand:

No ceiling, or one high enough that you forget it exists. A flat plan capped at ten users is a per-seat plan wearing a costume; you'll hit the wall and get routed to sales right as you grow. Look for no cap at all, or one you genuinely won't approach for years.

Every feature on every plan. The whole point of escaping per-seat is escaping the upsell calculus. If reports, exports, and billable flags are gated behind a higher tier, you've just moved the escalator. One plan, all features.

No card to try it. A flat price is a confidence signal; the vendor should be willing to let you prove it works before you pay.

For the record, this is the bet Janus makes: $29.99 a month, unlimited users, every feature on every plan, no per-seat math, and a 14-day trial with no card required. And because we'd rather you switch on arithmetic than on a pitch, here's the honest other side. Janus does not generate invoices — it exports clean CSV/PDF you feed into your billing tool. It's not a project-management suite; there's no kanban or task assignment. Tracking is manual and intentional — no background daemon guessing your hours. And there's no permanent free tier, so a solo user on a strict $0 budget may genuinely prefer a free-tier competitor. If those gaps are dealbreakers, a different tool is the right call, and we'll say so.

If they're not, the flat-pricing math is hard to argue with past about ten people. You can see the AI-native workflow on the Janus Claude skill, the integration surface in the REST API docs, or just start a free trial and run your own numbers. Either way, run the audit above first — the point of this playbook isn't that you should use Janus. It's that you should know what your pricing model actually costs you before you renew it.