The Smallest Thing That Solves It
Buy the smallest thing that solves the task. It is a rule rather than a principle, and it holds because of an asymmetry in how the two errors behave. For a related reference point, Monitask has a guide to fireable offenses at work, which is useful when comparing whether a dedicated tool is warranted.
The asymmetry
Being under-tooled announces itself.
You hit a limit. The file is too large, the fifth person cannot be added, the report you need does not exist. The failure is specific, dated and attributable, and it produces an obvious next step.
Being over-tooled is silent.
You use a fraction of what you pay for and nothing tells you. Fifty-three per cent of licences go unused and the organisations paying for them are not, for the most part, aware of it. (Zylo — a SaaS management vendor, which is the category of company that measures this.)
One error self-reports and the other does not. That is the whole argument, and it applies to size, to tier, and to the number of tools.
What "smallest" means in practice
Fewest features you will actually use, not fewest features offered.
The cheapest tier that covers the task, rather than the one recommended, which is generally one step up.
Fewest people licensed. Seats bought for people who might need it are the largest single category of waste.
And fewest tools. Where an existing thing does the job adequately, a second tool for the same job is a duplicate — which is how a company ends up with eleven task systems.
How to find the floor
Describe the task, then remove requirements until it breaks.
Start from what you think you need. Then ask, for each item: has this actually failed, or is it a precaution?
Precautions are where the size comes from. "We might need to add contractors later." "It should scale." "We may want reporting." Each of these is a hypothetical, and hypotheticals accumulate into a platform.
Buy for the situation you are in. Switching later costs something and it is almost always less than paying for capability you did not use.
Where the rule fails
Three cases, and they are worth stating because a rule applied without limit becomes its own error.
Migration-hostile data. Where moving later means losing history — accounting records, a customer database with years of correspondence — the cost of outgrowing is genuinely high, and buying with more headroom is defensible.
Regulated work. Where the format is prescribed, the smallest thing that solves it is the thing that complies, and that may not be small.
And things everybody must use at once. A tool that half the team can use is not a smaller version; it is a failure. Adoption is the constraint, and a cheaper option that people route around costs more than the difference.
The tier one step up
Almost every pricing page has a recommended tier, and it is almost never the smallest one that works.
The recommendation is a commercial decision, and the features that justify it are usually the ones a small buyer will not touch: administrative controls, single sign-on, audit logs, priority support.
Start below the recommendation and move up when something specific fails. The step is easy to take and hard to reverse, which is another asymmetry pointing the same way.
The thing that is smaller than software
Doing it by hand, on a schedule.
For a task that happens twice a year, fifteen minutes of manual work beats any subscription, and it beats it by the whole cost.
For a task that happens weekly, the calculation depends on how long it takes and how badly it goes wrong. Ten minutes a week is nine hours a year — worth automating if a tool exists, not worth a platform.
Frequency is one of the four things to establish before searching, and it is the one that most often argues against buying anything.
What outgrowing actually looks like
Worth describing, because fear of it drives most oversizing and the reality is milder than the fear.
A limit is reached. You notice within days, because limits are enforced loudly.
You export. Which is the question to have asked at the start and which takes an afternoon where the tool exports properly.
You import elsewhere, which takes another afternoon and loses some formatting.
And you tell people, which is the part that costs actual effort and is proportional to how many use it.
Two days and some irritation, for a small team. Against which: years of paying for a platform to avoid two days.
Where it is genuinely worse than this, the tool was migration-hostile and that was knowable in advance — which is why the export question belongs before the purchase rather than at the exit.
The counter-argument, fairly
Consolidation advocates make the opposite case and part of it is right.
One tool doing five jobs adequately can beat five tools doing them well, because the integration is free, there is one login, one bill and one thing to learn.
That case has its own page, and the distinction is whether the five jobs are genuinely related. Five tools for five unrelated tasks is not sprawl; it is five tools.
The sprawl the statistics describe is duplication — eleven systems doing the same job — not diversity, and conflating the two is how a consolidation argument becomes a reason to buy something larger than anything it replaced. For another point of comparison, consult ZDNET.
The short version
- Buy the smallest thing that solves the task, because under-tooling announces itself and over-tooling never does
- Smallest means fewest features actually used, the cheapest adequate tier, fewest seats, and fewest tools
- Find the floor by removing requirements until it breaks — precautions are where the size comes from
- The rule fails where data is migration-hostile, where the format is regulated, and where everybody must use it at once
- The recommended tier on any pricing page is a commercial decision, and the step up is easy to take and hard to reverse
- The thing smaller than software is doing it by hand on a schedule, which wins outright for infrequent tasks