Seat counts as a tax on growth: what per-user pricing does to a hiring plan

Per-user pricing sounds fair until you try to grow. Then you notice something strange. Every time you hire someone, your software bill goes up, and nobody in the budget meeting connected those two facts. Hiring a warehouse lead costs you a salary, benefits, payroll tax, and about $600 a year in project management seats. Then another $540 for the CRM. Then $300 for the document tool. None of it shows up on the hiring requisition, and all of it shows up on the renewal invoice.

That's a tax on growth. It's small enough to ignore at ten people and big enough to change decisions at eighty.

Take a mid-sized company running one main operations platform. Suppose it's $50 per user per month on the tier that has the automations and dashboards you need. Forty seats is $24,000 a year. Fine. Nobody quits over that.

Now grow. You hire fifteen people over eighteen months, and you add ten more the year after. At sixty-five seats you're paying $39,000. At ninety you're at $54,000. You haven't gotten any new features. You haven't asked for anything. You just hired people, and your vendor billed you for the privilege.

Then add the renewal increase. Vendors raise list prices. If your renewal moves up eight percent, that ninety-seat plan is closer to $58,000 the following year. Stack a CRM and a document platform on top with their own seat counts, and a company of ninety can easily clear six figures a year on software that mostly moves records from one status to another.

Here's the part that stings. Your cost per employee didn't go down as you grew. In every other part of the business, scale saves you money. You negotiate better freight rates. You spread fixed overhead across more revenue. Software seats do the opposite. They scale linearly forever, and the vendor has zero incentive to change that.

The billing model is annoying. The behavior it creates is worse.

Once seats have a price, somebody starts rationing them. It's always well-intentioned. The controller notices the renewal, asks who really needs access, and suddenly half the company is working from screenshots. I've walked into shops where the shop floor supervisors shared one login because the third seat wasn't approved. Two people editing the same schedule under one account, no audit trail, no idea who changed what. That's not a software problem. That's a pricing problem creating a software problem.

The other pattern is the read-only workaround. Vendors offer cheap viewer or guest tiers, so companies push half their staff onto them. Viewers can look but not update. So the people closest to the work, the technicians, the installers, the field crews, can't touch the record. Somebody with a full seat updates it for them, usually the next morning, usually from a text message. Your system of record becomes a system of secondhand reports.

Then there's the exported spreadsheet. When people can't get into the tool, they rebuild a piece of it in Excel and email it around. Now you're paying $54,000 a year for a platform and running the actual operation out of a workbook named "schedule_v4_FINAL.xlsx." I've seen this at companies that would describe their software as working fine.

The sticker price per seat is the easy part. The expensive surprises live around it.

• Tier jumps. The feature you need shows up on the plan that costs twice as much per user, so one requirement doubles your bill across every seat you own.
• Contractors and seasonal staff. A roofing company staffing up for summer either pays for seats it won't use in January or locks its temps out of the system entirely.
• Annual commitments with mid-year true-ups. You add people in March, get billed for a full year of seats, and can't remove them until renewal.
• Integration seats. Some vendors count service accounts, the automated logins your other systems use, against your total. You pay a human price for a robot.
• Partial users. The bookkeeper who touches the system four times a month costs the same as the project manager who lives in it.

That last one is where per-user pricing breaks down hardest for real companies. Usage isn't uniform. You've got ten heavy users, twenty occasional users, and forty people who need to see one screen and click one button. Seat pricing charges you as if all seventy are power users. The vendor's model assumes a software company full of knowledge workers. You run a distributor, a contractor, a clinic, a manufacturer.

A custom system changes the shape of the cost. Not always the size, but the shape, and the shape is what matters over five years.

You pay to build it once. That's a capital expense, and it lands in one or two fiscal years. After that, your recurring costs are hosting, a database, backups, and whatever maintenance and improvement work you want. Hosting an internal application for a hundred users is cheap. It's measured in tens or low hundreds of dollars a month, and it barely moves when you add users, because the cost driver is data and traffic, not headcount.

So the curve flattens. Going from forty users to ninety in a system you own costs you roughly nothing in licensing. You create fifty accounts. That's it. Compare that to the $30,000 a year of additional subscription you'd owe for the same growth.

Run the five-year comparison honestly. On the subscription side, add up your projected seat count each year, multiply by the annual per-user price, and apply a realistic renewal increase. Include every tool the custom system would replace. Include the integration middleware you pay for to keep those tools talking. Include the consultant you hire every time you need a new workflow configured.

On the ownership side, put your build cost in year one, hosting for all five years, and a realistic maintenance budget. Then compare totals. For a company that's growing headcount and running three or four overlapping platforms, ownership usually wins somewhere in year two or three. For a company of twelve that isn't growing, it usually doesn't. Do the math for your numbers, not for the ones in an article.

Plenty of times, honestly. I'd rather tell you that than watch you spend money on a build you don't need.

If your headcount is flat, seat pricing is predictable and cheap. Twenty seats that never change is a rounding error, and the vendor handles security patches, uptime, and mobile apps for you. That's real value.

If the software is highly specialized and heavily regulated, buy it. Payroll, tax filing, medical billing, and accounting all have rules that change every year. A vendor amortizes that compliance work across thousands of customers. You'd be paying a developer to chase IRS updates. Bad trade.

If your team genuinely uses the depth of the product, buy it. Salesforce is enormous because some companies really do use the forecasting, the territory management, and the ecosystem. If you're one of them, a custom rebuild would be a downgrade dressed up as savings.

The candidates for ownership look different. They're companies paying for a lot of seats to use a small slice of a platform, patching between two or three tools, and adding people every year. That's when the seat tax gets loud.

Owning the system removes the seat tax. It doesn't remove work, and anybody who tells you otherwise is selling.

You inherit responsibility. Nobody else is watching your uptime at 2am. You need a maintenance arrangement, whether that's the firm that built it or someone in-house. Software you own but don't maintain rots quietly for two years and then breaks on the worst possible Tuesday.

Migration is real labor. Moving eight years of records, attachments, and comment history out of a hosted platform takes a scripted export and a lot of validation. Some vendors make bulk export of files genuinely painful. Custom fields don't map cleanly. Historical data always has garbage in it that nobody noticed because nobody ever reported on it.

You also lose the free feature stream. Your subscription buys you improvements you didn't ask for, and some of them are good. Mobile apps get faster. New integrations appear. A custom system improves when you decide to pay for improvements. That's control, and control means the roadmap is now your job.

And external sharing gets harder. If your clients log into your vendor's platform to see their projects, replacing it means building a client portal. That's doable and often better, but it's scope, and it changes the honest comparison.

You don't need a consultant to run the first pass. You need an afternoon and your renewal invoices.

1. List every per-seat tool, its price per user, and its current seat count. Total the annual spend.
2. Pull your hiring plan for the next three years and recalculate that total at each year's headcount.
3. Ask each department which screens and reports they use weekly. Write those down. That's your real requirements list.
4. Note where people share logins, work from exports, or wait on someone else to update a record. Those are the places the seat tax is already costing you accuracy.
5. Get a build estimate scoped to the requirements list from step three, and compare the five-year totals side by side.

If the numbers are close, stay on the subscription. Close isn't a reason to take on a project. If ownership wins by a wide margin and your headcount is climbing, you're paying a growth tax that compounds every year you wait.

We build these systems in Clearwater for companies across Pinellas and Hillsborough counties, and the first question we ask is always the same one. What does this cost you at your year-three headcount? If you want help running that arithmetic on your own numbers, book a free strategy session at /contact. Bring the invoices and the hiring plan.