Once a month, I sit down with the actual TLG billing dashboard and go through every SaaS subscription line by line. Not a quarterly review, not an annual audit when someone finally notices the number looks big. Every month, every tool, no exceptions for the tools people like. That discipline is not glamorous, but it is one of the more consequential habits I run as founder, and it is worth explaining exactly how it works, because most small firms either never do this or do it so rarely that the damage has already compounded by the time they look.
Why Monthly, Not Quarterly
Subscription costs do not grow in dramatic jumps. They creep. A seat gets added for a contractor who leaves two months later and nobody removes the license. A tool gets upgraded to a higher tier for one feature a single project needed, and then nobody downgrades it after the project ends. None of these are large individually. Reviewed quarterly, they are easy to miss because the total still looks roughly normal. Reviewed monthly, a new or upgraded line item is immediately visible against last month's baseline, and you can ask the question while you still remember why it happened.
The mechanic is simple: export the recurring charges, sort by tool, and compare to the prior month, every single month, on a fixed day. It takes under an hour once it is a habit. The value is not in the hour spent, it is in never letting three months of drift accumulate into a number that requires a painful conversation to unwind.
Unit Economics, Not Just Line-Item Cost
The number on the invoice is not the number that matters. The number that matters is cost per unit of output the tool actually produces for the business. A project management tool costing a certain amount a month is expensive if only two people log into it, and cheap if it is genuinely load-bearing for how the entire team coordinates work. Judging a tool by sticker price alone gets the decision backwards more often than it gets it right.
At TLG, our stack includes tools like Netlify for hosting and deployment, Supabase for data and durable state, HubSpot for the CRM and pipeline motion, Stripe for payments, AWS for infrastructure, and Slack for internal communication. I am not going to publish what any of those cost us, because pricing is not the point and it changes. What matters is the framework: for each one, I ask what would actually break if we cancelled it tomorrow, and how many hours or how much revenue that break would cost us in the following thirty days. A tool that would quietly go unnoticed for a month if it disappeared is a candidate for cancellation regardless of its price. A tool that would stop client-facing work within a day is worth paying more for, not less.
When to Keep a Tool That Looks Expensive
The instinct in a cost review is to hunt for the biggest number and cut it. That instinct is wrong often enough that I actively correct for it. Some of our highest-cost tools are also our highest-leverage tools, and cutting them to save money would cost more in rework, delay, and lost deals than the subscription itself.
The test I actually use: does this tool sit in the critical path of revenue generation or client delivery, and would replacing it with a cheaper alternative cost more in migration time and lost functionality than we would save in the first year. If both answers point toward keeping it, I keep it, and I stop feeling guilty about the number. A cost review that treats every expensive line item as a problem to be solved is not financial discipline, it is a bias dressed up as diligence.
When to Kill a Tool Everyone Likes
The harder move, and the one most founders avoid, is killing a tool that people genuinely enjoy using but that is not earning its place. Almost every team has at least one subscription that survives review after review purely on sentiment. Someone likes the interface, someone is used to the workflow, and nobody wants to be the person who takes it away.
I have cancelled tools exactly like this at TLG, tools with genuine fans on the team, because the actual usage data showed the function could be absorbed into something we were already paying for. The way I handle it is not by ambushing the decision. I bring the usage data, I name the overlap with an existing tool, and I set a real transition window instead of cutting access the same day. That removes most of the emotional resistance, because the conversation is about data and timeline, not about taste.
A Quick Gut Check for Every Tool on the List
- Who logged in this month, not who has a license. Unused seats are the single most common silent cost in a small firm's stack.
- What breaks without it, stated specifically, not generally. "It would be inconvenient" is not the same answer as "client invoicing stops."
- Is there overlap with another tool already in the stack that could absorb the function with acceptable friction.
- Has the price changed since the last renewal without a corresponding conversation about whether the value changed too.
The Contrarian Move: Pay More for the Tool You Actually Use
Here is the position that tends to surprise people. I would rather pay more for one tool the team uses every single day than pay less in total for three tools that each get touched once a week. Three cheap, underused tools create more hidden cost than one expensive, fully adopted one, because the hidden cost is not on the invoice. It is in context switching, in duplicated data entry, in the mental overhead of remembering which tool holds which piece of information. A consolidated stack built around fewer, more expensive, more deeply used tools almost always outperforms a sprawling stack optimized purely for the lowest line-item price.
This runs against the instinct most cost-cutting advice pushes, which is to always find the cheaper alternative. Cheaper is not free if it costs your team an extra ten minutes a day working around its limitations. Multiply that ten minutes across a team and a year, and the "savings" evaporate fast.
No Sacred Cows, Including the Tools I Personally Like
The discipline only works if it applies to everything, including tools I personally prefer using. I have gone through this review and cut something I liked because the usage data did not justify it, and I have kept something I found mildly annoying because the business case for keeping it was airtight. The review is not about preference. It is about running the numbers the same way every month and following where they point, even when that is inconvenient.
Small firms do not have the margin to carry SaaS bloat the way larger companies can absorb it without noticing. A disciplined monthly review is one of the least expensive habits a founder can build, and it compounds every month you keep doing it.
If you want a second set of eyes on how your own stack stacks up against this kind of review, or you are trying to figure out where your cloud and SaaS spend is actually going, that is exactly the kind of conversation worth having on a discovery call.