How to calculate the real cost of per-seat licensing before your next renewal

• Per-seat pricing is a starting point, not a total. The real annual figure is usually a third higher than the line item on the invoice.
• Count your seats by role. Read-only viewers, dormant accounts, admin logins, and integration users are often billed at full price.
• Internal admin time is a real cost. Someone on your payroll maintains that platform every week.
• A five-year projection with a compounding uplift tells you more than any vendor comparison chart.
• Ask about uplift caps, seat reduction rights, and data export terms before you sign, not after.
• A custom build is not the answer for commodity functions like email, accounting, or payroll.

Every per-seat quote starts with a friendly figure. Say it's ninety-five dollars per user per month. Sixty people, so five thousand seven hundred a month, or sixty-eight thousand four hundred a year. Clean math. Then the real invoice arrives.

The first surprise is the tier jump. Most platforms gate the features you actually need behind a higher plan. Approval workflows, custom fields beyond a certain count, role-based permissions, decent reporting. You wanted three features and you bought a whole tier for everyone.

Then come the add-ons. A separate module for time tracking. Another for resource planning. A per-record fee for documents. API access, which is the ability for your other software to talk to this software, priced as its own line. A sandbox, meaning a safe copy where you test changes before they hit live data, billed monthly. Storage overages once your attachments pass a threshold nobody warned you about. Premium support, because standard support means a web form and a two-day wait.

Last is the uplift. That's the automatic annual price increase written into your contract. Five percent is common. Seven and ten are no longer rare. It compounds, which means year five costs far more than year one for the exact same software.

This part takes about an hour with an export from your admin panel. Most platforms let you download a user list with last login dates. Get that file.

Sort your people into buckets. Heavy daily users who genuinely need the tool. Occasional users who log in a few times a month. Read-only viewers who only want to see a status or a report. Admin and service accounts. Integration users, which are logins your other systems use to push and pull data automatically. Contractors and seasonal staff.

Now check what you pay for each bucket. On most platforms, the answer is the same price for all of them. A person who opens a dashboard twice a quarter costs what your project manager costs. An automated login that moves data between two systems costs what a human costs. That's where the waste hides.

Count the accounts with no login in ninety days. Count the duplicates from people who left. Count the seats you bought for a client who wanted visibility and then never used. Add up what those cost you last year. For a sixty-seat company, fifteen dead or barely-used seats is seventeen thousand dollars a year for nothing.

One more line. Write down how many seats you expect in three years. If you're growing, per-seat pricing punishes growth. If you're flat or shrinking, check whether your contract even lets you reduce seats at renewal. Plenty don't.

Someone at your company runs that platform. They build the views, fix the automations, onboard new users, and rebuild reports when a field changes. Ask them honestly how many hours a week that takes. Multiply by their loaded hourly rate and fifty weeks. Five hours a week from a sixty-five dollar an hour operations manager is over sixteen thousand dollars a year, and that person is not doing their actual job during those hours.

Then there are the glue subscriptions. Most companies running a big SaaS platform also pay for a connector tool to bolt it to their accounting system, plus a form builder, plus a reporting layer because the built-in reports don't answer the questions leadership asks. Each one is a monthly charge and a login and a thing that breaks.

Add the outside help. Major version upgrades often need a consultant. So do reconfigurations after a reorg. Those invoices are lumpy and easy to forget, so go dig them out of your accounting system for the last three years and average them.

Finally, the exit cost. Getting your data out of a mature platform is a project. Records export reasonably well. Attachments, comment threads, audit history, and the links between records usually need a scripted pull through the API over several days. If you ever plan to leave, that bill exists whether you plan for it or not.

Take your true all-in annual number. Using the example above, that's sixty-eight thousand in licensing plus roughly twenty-five thousand in admin time, connectors, and consultants. Call it ninety-three thousand for year one.

Apply a seven percent uplift each year. Year two is ninety-nine thousand. Year three is one hundred and six. Year four is one hundred and fourteen. Year five is one hundred and twenty-two. The five-year total lands around five hundred and thirty-four thousand dollars. That's what renewing costs you, assuming your headcount never grows.

Now the other column. We don't publish build prices, and nobody can quote your system from a blog post. So do this in multiples instead. Get a fixed-scope quote and express it as a multiple of your current annual spend. Then add yearly hosting and maintenance, which for a well-built internal system typically runs fifteen to twenty percent of the build figure.

Suppose a quote comes back at two and a half times your current annual licensing cost, with maintenance at eighteen percent per year after that. Cumulative custom spend is about one hundred and seventy-one thousand in year one, two hundred and two in year two, two hundred and thirty-three in year three, two hundred and sixty-three in year four. Compare that to the subscription column. The lines cross during year four. By year five you're roughly a hundred thousand dollars ahead, and you own the software.

Change any input and the answer changes. That's the point. Build the sheet with your numbers and you stop arguing about philosophy and start arguing about arithmetic.

Renewal conversations are negotiations, even when they don't feel like one. Reps have room on multi-year terms and almost none in the final week before expiry. Start ninety days out.

• What's the contractual cap on annual price increases, and will you put it in writing for the full term?
• Can I reduce seat count at renewal, and by what percentage without penalty?
• What happens to my price if I drop a module or downgrade a tier?
• Are API calls, sandboxes, and storage included at this tier, and what are the overage rates?
• On termination, what format is my data delivered in, how long do I have to retrieve it, and is there a fee?
• If you're acquired or the product is sunset, what are my rights?

Write the answers down. Vague verbal reassurance from a rep who'll have a different territory next year is worth nothing at your next renewal.

There's no universal seat count, but there are reliable signals. Custom starts winning when your per-seat spend is high, your process is unusual, and your seat count is stable enough that you're not buying growth insurance.

In practice, the math tips when your all-in annual spend passes roughly sixty to eighty thousand dollars and your uplift is five percent or more. It tips faster if you're paying full price for read-only users, because a system you own can hand out unlimited viewers for free. It tips faster again if your team runs spreadsheets alongside the platform, because that means you're paying for software that doesn't fit and paying people to work around it.

It tips the other way when you're growing fast and unpredictably, when your process is standard, or when the platform is the hub of a network you don't control.

A custom build is the wrong answer for commodity software. Email, accounting ledgers, payroll, and tax filing are solved problems with cheap, mature products. Buy those. Nobody should build a general ledger.

External network effects are real. If your clients, subcontractors, or insurers already log into the platform you're using, replacing it means changing their habits too. That cost is genuine and it's usually underestimated.

A build also has a ramp. There's a period where you're paying for the new system while still paying for the old one, and you'll run both in parallel for a stretch during cutover. Your five-year model should include that overlap year honestly.

Ownership shifts responsibility, not just cost. When something breaks at 2am, there's no vendor status page. You need a maintenance arrangement, documented code, and credentials in your own name. Get all three in writing before the first line of code is written.

And migration is work. Twelve years of attachments, threaded comments, and audit history come out through scripted exports over days, not through a copy and paste. Budget for it.

Pull twelve months of invoices. Export your user list with last login dates. Bucket the seats by role and flag anything dormant. Add admin hours at a loaded rate. Add every connector, reporting tool, and consultant invoice. Build a five-year column with your actual uplift. Get one fixed-scope build quote and express it as a multiple of annual spend. Compare the cumulative totals. Then call your rep with the numbers in front of you.

Most operations leaders finish this and find the real number is thirty to forty percent above what they thought. That alone changes the renewal conversation.

If your numbers point toward owning the system instead of renting it, we can help you pressure-test the model before you commit. Black Badger builds software our clients own outright, from our office in Clearwater. You can book a free strategy session and bring your worksheet.

How much higher is the real cost than the quoted per-seat price?

For most mid-sized companies, thirty to forty percent higher once you add admin labor, connectors, and consultant invoices. If you're paying storage or API overages, it can be more.

Can I really negotiate the annual uplift?

Yes, and more often than people expect. Ask for a hard cap in the contract language, and offer a longer term in exchange. Reps have quotas and quarter ends, and starting ninety days early gives you power you lose entirely in the final week.

What if we're growing quickly? Does that change the math?

It cuts both ways. Fast growth makes per-seat pricing more expensive every year, which favors owning. But unpredictable growth makes scoping a build harder. If you can't forecast headcount within twenty percent, renew short and revisit.

Do we lose support if we build our own system?

No, you change who provides it. You sign a maintenance agreement instead of a subscription. The difference is you own the code, so you can take that agreement elsewhere if you're unhappy.

Should we replace everything at once?

Almost never. Replace the piece that costs the most and fits the worst. Keep the rest connected while you prove the first module works.

Build versus buy: a decision framework for operations leaders walks through the same question from the other direction, starting with fit rather than cost.

• Vendor lock-in warning signs to check before your next contract
• What it really takes to migrate data out of a SaaS platform
• Who owns your custom software, and how to make sure it's you