The quarterly tool review: how we keep software subscriptions, costs and access under control

Software costs creep. A team signs up for a design tool trial and forgets to cancel. Someone buys an annual plan for a project that ended in the spring. Three companies in the same group each pay separately for nearly identical form builders. A contractor who finished months ago still has admin access to an analytics account. None of these is dramatic on its own. Together they add up to real money, real security risk and a fuzzy picture of what each business actually costs to run.

The fix is not a large procurement process. It is a quarterly tool review: a short, recurring meeting and a single inventory that answer five questions about every tool the business uses. What is it? Who owns it? Which company does it belong to? What does it cost? Who can access it?

We run this review across Oryvelon and every company in the group. It fits our broader habits — cost discipline, least-privilege access and companies that could each stand alone. This article describes how it works so you can run your own.

Why tool sprawl happens

Tool sprawl is the natural result of a few ordinary behaviours.

Trying things is cheap. Most software offers a free trial or a low monthly price. Signing up takes minutes, and the decision is often made by one person solving one problem.

Cancelling is nobody's job. The person who signed up moves on to the next problem. The subscription renews automatically. No one notices because the charge is small and lands on a card statement nobody reads line by line.

Per-seat pricing hides growth. A tool that cost little for two people costs much more for twelve, and seats are rarely removed when people change roles.

Groups multiply the effect. In a group of companies, each company solves the same problems independently. Without a shared view, you end up with several tools for the same job, each on its own plan.

Access outlives need. Contractors, former team members and one-off collaborators keep their accounts because removing access is a separate step nobody remembers.

A quarterly review addresses all five with one habit.

The inventory: one list of everything

The review is only as good as the inventory it works from. Ours is a single structured list — a shared table is enough — with one row per tool or service. It covers more than obvious SaaS subscriptions:

• software subscriptions (design, documents, project management, email, support desks);
• infrastructure and hosting (servers, databases, storage, CDN, domain registrars, DNS);
• AI model provider accounts and the AI gateway's per-product projects;
• analytics, search console and advertising accounts;
• commerce platforms, payment providers and their apps;
• developer tools and code hosting;
• service accounts and API keys that belong to systems rather than people.

Each row carries the same fields:

The "data held" column is easy to skip and important to keep. A tool that stores customer data needs a different level of care from one that stores only internal notes. It also tells us which tools matter when a customer asks for their data to be deleted. See Data retention and deletion.

Building the first inventory

If you do not have an inventory, build the first version from three sources: card and bank statements for the last twelve months, the list of accounts in your password manager or single sign-on system, and a short message asking everyone "what do you log into for work?". The overlap between those three lists is most of your stack. The gaps are where the surprises live.

Every tool has an owner

The single most useful rule in the review is that every tool has a named owner. Not a team — a person.

The owner is accountable for four things: that the tool is still needed, that its cost is justified, that access is appropriate and that renewals do not happen by accident. They are not necessarily the heaviest user. For a company's support desk, the owner might be the person responsible for customer service; for its hosting, whoever is responsible for that company's infrastructure.

During the review, any tool without an owner gets one immediately or is scheduled for cancellation. "Nobody owns it" is not a stable state. It is how forgotten subscriptions keep renewing.

Ownership also follows the company. A tool used by MerchNivo is owned by someone responsible for MerchNivo, not by the group in general. That keeps decisions close to the people who understand the need.

Finding duplicates

The second pass looks for tools that do the same job.

Inside one company, duplicates usually come from different people solving the same problem at different times: two note-taking tools, two form builders, two file-sharing services. The fix is to pick one, migrate what matters and cancel the other.

Across companies, the question is more interesting. Suppose several companies each pay for a similar tool. Should they share one?

Our answer depends on what the tool holds.

• Tools that hold no customer data — internal design, documentation, code hosting for shared libraries — can often be shared at group level, with clear per-company workspaces. This is the "shared infrastructure" part of our principle.
• Tools that hold customer or user data — support desks, email marketing platforms, analytics, commerce platforms, the product databases — stay separate per company. Consolidating them would save a little money and break the boundary that matters most to us. See Shared infrastructure, separate data.

So the duplicate check is not "one tool per job across the whole group". It is "no accidental duplicates, and deliberate separation where data is involved". A group that consolidates customer data tools to save a few subscriptions has made a bad trade.

A simple table helps in the meeting:

The last row illustrates a subtle point. Using the same vendor across companies can be sensible — the team knows it, the setup is repeatable — as long as each company has its own account, its own lists and its own consent records. Same tool, separate data.

Attributing cost to the right company

Cost attribution is where the tool review connects to the rest of how we run the group.

Every Oryvelon company has its own unit economics: what it costs to acquire and serve a customer, and what each customer brings in. Those numbers are only honest if the company carries its real costs. If the group quietly pays for a company's support desk, analytics and hosting, the company looks healthier than it is, and decisions at the 30/60/90-day checkpoints are made on flattering numbers. See Unit economics per product.

So every row in the inventory is attributed to a company. Where possible, the tool is billed directly to that company. Where infrastructure is genuinely shared — the AI gateway service, shared build tooling, a group-level password manager — its cost is split by a simple, documented rule:

• By usage where usage is measurable, such as AI calls per product through the gateway, which already records cost per product. See Building an AI gateway.
• By seats where the tool is priced per user and users belong to companies.
• Equal share for small fixed costs where measuring usage would cost more than the precision is worth.

The rule is written down and applied the same way every quarter. Nobody negotiates their share in the meeting.

This matters beyond accounting. If a company were ever separated from the group, its inventory rows are the list of accounts that need to move with it. Because each tool is already attributed, that list exists before anyone needs it.

The access review

The cost part of the review saves money. The access part prevents incidents, and in our view it is the more important half.

For every tool in the inventory, the owner checks:

1. Who has access? Compare the user list with the people who actually need it now.
2. Who has left or changed role? Remove former team members, finished contractors and people whose work no longer requires the tool.
3. Who has admin rights? Reduce admins to the minimum. Most people need to use a tool, not configure it.
4. Is two-factor authentication enforced? For every human account. If a tool cannot enforce it, note that and consider whether it should hold anything important.
5. Are there shared logins? Replace them with individual accounts wherever the tool allows. Shared logins make it impossible to know who did what and hard to remove one person's access.
6. Which service accounts and API keys exist? Confirm each still belongs to a running system, has the narrowest permissions it needs, and has an owner. Rotate anything that has been exposed or is overdue.

We apply least privilege everywhere, and the quarterly review is where it gets checked in practice rather than assumed. People join, projects end and roles shift; access drifts accordingly. Once a quarter, it is pulled back to what it should be. See Least-privilege access for small teams.

Some tools deserve extra attention in the access review because of what they control:

• Domain registrars and DNS. Whoever controls these can redirect a company's website and email. Access should be minimal and two-factor enforced. See Domain, DNS and email security.
• Payment and commerce platforms. Refunds, payouts and customer data live here. Noveniq's store admin is reviewed carefully each quarter.
• Model provider accounts. Each product has its own AI project and keys; the review confirms that keys belong to the right product and that budgets and limits are in place.
• Tools holding children's or sensitive data. For EduRelia, access to anything that touches student data is kept to the smallest possible group and reviewed without exception.

How the meeting runs

The review itself is short. For a small company it takes under an hour; for the group as a whole, a few hours spread across company owners.

Before the meeting, each owner updates their rows: current cost, seat count, admin list, renewal dates. The inventory is sorted by renewal date so upcoming commitments are visible.

During the meeting, we walk through the list in four passes:

1. Ownerless tools. Assign or cancel.
2. Renewals in the next quarter. Especially annual plans. Renew deliberately, downgrade or cancel.
3. Duplicates and underused tools. Low usage, overlapping purpose or no activity since the last review.
4. Access exceptions. Anyone flagged by owners: former members still present, excess admins, missing two-factor authentication, shared logins.

After the meeting, owners complete the actions within a set period — usually two weeks — and mark them done in the inventory. The actions and their status are recorded next to the inventory, so the next review starts by checking that the last one's actions actually happened.

The review fits into the broader rhythm described in The operating cadence behind a portfolio of digital businesses: weekly health checks, monthly snapshots, quarterly reviews of tools, access and direction.

A worked example

Imagine a quarter in which the review of one company turns up the following. None of this is a real result; it is the kind of list the review typically produces.

• An annual plan for a video editing tool renews next month. Its owner used it for a launch campaign two quarters ago and not since. Decision: let it lapse; switch to a monthly plan if needed again.
• Two people have admin rights on the support desk. One moved to another company in the group last quarter. Decision: remove their access here; they keep access only in the company they now work for.
• A form builder was added by a contractor for a one-off survey. It has no owner, and its responses include email addresses. Decision: export what is needed, delete the rest in line with retention rules, cancel.
• The company's hosting bill has grown steadily. Usage explains it — the product is busier. Decision: no change, but add a budget alert.
• A service account key for an old integration is still active. The integration was removed. Decision: revoke the key.

Five actions, a modest saving, three fewer ways for something to go wrong. That is a typical outcome. The value compounds because the same small corrections happen every quarter instead of piling up for years.

Tools in a new company

New companies are where sprawl starts, so we set a simple default. A company in validation uses the smallest possible set of tools, preferably ones the group already runs well, each added to the inventory the day it is created with an owner and the company recorded. Paid plans wait until the company passes its first checkpoint. If the company stops, the inventory is the checklist for closing everything down: cancel subscriptions, export or delete data under its retention rules, revoke keys and remove access.

Signs you need a tool review now

If you do not run one yet, a few signs suggest it is overdue:

• nobody can say, without checking, how many software subscriptions the business pays for;
• card statements include charges no one immediately recognises;
• people who left months ago still appear in user lists;
• several tools do the same job, and different teams use different ones;
• you are unsure which tools hold customer data;
• annual renewals arrive as surprises.

Any one of these is a reason to build the inventory this month rather than next quarter.

Common mistakes

1. Reviewing cost but not access. Saving money on seats while leaving former contractors with admin rights gets the priorities backwards.
2. Owners as teams. "Marketing owns it" means nobody does.
3. Consolidating data tools across companies to save money. A small saving that dissolves a boundary you will want later.
4. Not normalising annual plans. A large annual charge hidden in one month distorts every monthly cost comparison.
5. Forgetting non-human accounts. Service accounts and API keys are often the most privileged access in the business and the least reviewed.
6. Not closing the loop. A review whose actions are not tracked becomes a meeting that produces the same list every quarter.

Summary

The quarterly tool review is a short, recurring check that keeps software costs, duplicates and access under control. We keep one inventory of every tool, subscription and service account across Oryvelon's companies, give each a named owner, look for accidental duplicates while keeping customer data tools deliberately separate per company, attribute every cost to the company that uses it, and review access with least privilege and two-factor authentication as the standard. It takes a few hours a quarter. In return, each company knows what it really costs to run, carries only the tools it needs and gives access only to the people who need it now.

Questions and answers

What is a quarterly tool review?

A quarterly tool review is a recurring check of every software tool and subscription a business uses, covering who owns it, what it costs, whether it duplicates another tool, which company it belongs to and who has access.

Why review tools every quarter rather than once a year?

Subscriptions, seats and access change constantly, and many renewals happen monthly or at different points in the year. A quarterly review catches unused seats, forgotten trials and stale access before they accumulate.

How does Oryvelon attribute shared tool costs to its companies?

Each tool is recorded against the company that uses it. Where infrastructure is genuinely shared, its cost is split by a simple documented rule, such as usage or an equal share, so each company's costs reflect what it consumes.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Growth, Search & Measurement

NextIntroducing Oryvelon: the group behind our companies →