The upgrade email usually arrives about three weeks after the hire that caused it. You crossed some line, a fiftieth employee, a second country, a manager who now has to approve something, and the capability you need to keep working is on the next plan up. Nothing was shipped to you. The code was already running, on the servers your data was already sitting on, and somebody changed a field on your account.
That is the whole argument in one paragraph. In almost every other market, paying more gets you more of something that costs more to make. Here, paying more removes a restriction that cost money to build.
The database that used to be hard
It was not always like this. An HR information system in 1995 was genuinely difficult to construct. Effective-dated records, so you could ask what somebody’s salary was on a date rather than what it is now. An org chart that survives a reorganisation without losing history. Permissions fine enough that a manager sees their team and not the company. All of it on a licensed relational database, on a machine somebody owned, installed by consultants over months and maintained under an annual contract. The price was defensible because the work was real and most of it happened in your building.
Then, over about fifteen years, every hard part became a commodity. Hosting became somebody else’s problem, the database became a managed service, and authentication, file storage, mail delivery and background jobs became configuration rather than engineering. What stayed difficult moved out of the infrastructure and into the domain: what a probation period does to a notice calculation, what a leave balance owes somebody on their last day, what a country requires on a payslip. That is real work, and it is not an installation project.
Prices are stickier than cost curves. When the cost of building collapses and the expected price does not, something has to hold the price up, and the industry found its answer in packaging. Take the one product you built, sell it as three, Basic, Professional and Enterprise, and let the feature list conduct the negotiation a salesperson would otherwise have to conduct in the room. The product stopped being the thing you sell and became the thing you withhold.
None of this was a conspiracy. Versioning is a well understood strategy whose purest form predates software: a manufacturer adds components to a machine to make it slower, so the cheap version cannot undercut the expensive one. Software made it cleaner, because degrading a product there costs nothing. It is a flag.
The boundary moves to where it hurts
Now ask where you would draw the line between the middle plan and the top one, if your goal were revenue rather than description. Not where your costs change, because they mostly do not. You would draw it where the buyer’s need becomes non-negotiable.
Look at what lives above that line across the category and the family resemblance is obvious. Approval chains, which nobody needs until there is a second layer of management. Audit and access review, which nobody asks for until a customer sends a security questionnaire. Custom fields and an API, which matter on the day you acquire a second system that has to agree with the first. Single sign-on, which becomes urgent the week IT takes over identity. Advanced reporting, which you buy after the board asks a question you cannot answer from the record you already own.
Every single one of those is a growth event. That is what makes the pattern a tax on growing rather than a price for a thing: the trigger is not your consumption of the vendor’s infrastructure, it is your own progress. You are billed for the fact that the company worked.
Migration cost is the leverage
The reason it holds is that the moment you need the capability is the worst possible moment to argue about what it costs.
Consider the alternative you are implicitly offered: move an HR system with forty people in it. Historical records, documents attached to individuals, leave balances that reconcile to the day, and the manager permissions somebody spent a week getting right. Even a well run migration costs weeks of attention, and it lands in the quarter that produced the growth event, which is the quarter when nobody has weeks. The real cost of moving an HR system is mostly not the software.
So the buyer does the arithmetic, and the upgrade wins. It nearly always wins, and the vendor knows it will before the call starts.
That is worth naming plainly, because pricing conversations are conducted in the language of value. Value is what a thing is worth to you. Leverage is what refusing it costs you. A price set on leverage looks exactly like a value price from the inside, and the difference only shows up when you try to leave.
The fair version of the counter-argument
Some features genuinely do cost more to run, and any argument that skips this is dishonest.
Anything consuming resources in proportion to use costs more when used more: document storage, long retention, high-volume integration traffic. Anything requiring human work per customer costs more per customer: implementation, migration assistance, a named support contact. Anything carrying external maintenance carries it forever, such as country compliance content that has to be corrected when a rule changes. And anything carrying compliance weight brings procurement, questionnaires and audit obligations with it, onto a team that was previously building.
Those costs are real and recurring, and roughly proportional to something you can point at. A vendor that charges for them is not taxing you, it is passing on a cost, and a vendor that refuses to either subsidises heavy users from light ones or eventually stops existing. The single sign-on case is the sharpest example, because identity integration genuinely does generate support and compliance load. The objection was never that it should be free.
The test is what the price tracks
So the line is not between free things and paid things. It is one question, asked of every number on the page: does this price track what the capability costs to run, or does it track how badly the buyer needs it?
Four checks make that answerable from outside. Does the vendor’s cost rise when you use the feature more? Storage does, an approval workflow does not. Would withholding it from a ten-person customer save the vendor anything? If not, the withholding is itself the product. Is the capability priced as a feature, with its own number and its own unit, or bundled behind a tier so the tier is the only door? And has the price ever come down, given that the cost of running software falls year after year? A price tracking cost drifts downward. A price tracking need holds.
That is the principle. Applying it to a live pricing page, where units differ per module and half the cost is printed nowhere, is a separate skill, and reading one adversarially is the practical companion to this piece.
Where we stand
An argument does not make a price honest, so ours is testable instead: the core is free up to twenty people and identical on every plan above that, a plan changes how many people you can carry and whether you can enable modules and nothing else, and every module carries a published price on its own unit on one page rather than a quote. Where we think charging is defensible, and which parts of our own cost base we think justify a price, is argued at length in the manifesto.
The more useful thing to say is what we do not do. The capability closest to real recurring cost in this category is payroll, and we do not run it: the module compiles the inputs Capstan already holds into a documented export for your payroll partner and files their computed results back onto the record, and it holds no statutory rate, slab or formula of its own. Enterprise identity, meaning single sign-on and IP restriction, is not built either, so no plan here withholds it from you. What is built, and what each piece costs, is listed in the module catalogue. A ladder that implies more than that would be doing exactly the thing this post is about.