.png)
Most tool decisions get framed as a simple yes or no, pay for the upgrade or do without. The more useful question is a third one: can a smarter build deliver the same result on the plan you already have. Often it can, and the savings compound every single month.
The fork in the road
A scaling business needed role specific access, so each department could see and edit only the parts of the system relevant to them. Their tool offered that natively, but only on a higher tier that more than doubled the per user cost. Across a full team, that upgrade meant a significant recurring expense for what amounted to a single feature.
The reflexive move is to upgrade. It feels responsible, like investing in the business. But reflexive upgrading is also exactly how software waste accumulates. According to Zylo's 2025 SaaS Management Index, organisations now spend thousands of dollars per employee on software each year, and Ramp's analysis of unused subscriptions found the average organisation wastes well over one hundred thousand dollars a year on licences and tiers it does not fully use. A meaningful slice of that comes from buying the bigger plan for one feature.
Designing with the price as a constraint
Rather than reaching for the credit card, we took a different route when building for this company. Instead of relying on the platform's built in permissions, the system used separate fields for each department's view of a record. One department worked from its own status field, another from its own, and carefully constructed views showed each team only what concerned them. Automations kept everything in sync. The practical effect matched role specific access, while the business stayed on the lower priced plan.
This is not cleverness for its own sake. It is a deliberate trade with real terms on both sides. The workaround adds a little complexity to the build and requires explaining to the team why there are, say, two status fields rather than one. Set against more than doubling the per user cost indefinitely, that was clearly the right call for this stage of the business. Choosing the route that fits is the core of choosing business automation tools that actually work: the best tool decision is the one that matches your real needs and your real budget, not the one with the most checkboxes.
When to upgrade anyway
Designing around pricing is a discipline, not a religion. Sometimes the higher plan is genuinely worth it, and you should pay for it without guilt. The native feature may be more robust, easier for your team to understand, or safer over the long run than a workaround you have to maintain.
The skill is in telling the two situations apart, which is really the everyday version of the specialist versus generalist software dilemma. Ask whether the feature is the only path to the outcome, or merely the most obvious one. Ask what the workaround will cost you in ongoing complexity, and weigh that honestly against the recurring price of the upgrade. If the workaround is fragile or confusing, the upgrade may be cheaper in disguise. If it is simple and stable, you have just saved real money for no real loss.
The habit worth building
The wider lesson is that software pricing is not a wall you either pay to climb or stand helplessly beneath. It is a constraint you can design around, the same way a good architect designs a beautiful building within a fixed budget rather than ignoring the budget and hoping.
That mindset starts with separating what you need from what the vendor would prefer you buy. Before upgrading for a single feature, pause and ask whether that feature is truly the only way to reach the outcome. A thoughtful structure on a smaller plan frequently gets you most of the benefit at a fraction of the cost, and knowing when that applies is one of the most quietly profitable skills a growing business can develop.
