Not everything is mission critical. For a small team, accepting that is one of the most freeing things you can do, and one of the hardest.
When you run lean, the instinct is to protect everything equally. It feels responsible. In practice it does the opposite. If every system has to meet the highest bar before it is allowed to exist, you stop building. The effort it takes to make something bulletproof becomes the reason nothing new ever ships. You end up safe and stuck at the same time.
The way out is to rate things on a scale of criticality, one to ten, and decide on purpose where each one sits.
A ten is mission critical. You cannot afford it to be down at all. If it fails, it is all hands on deck until it is back. A one is a nice to have. If it quietly disappeared and never came back, no one would notice. Most of what you run lives in the broad middle, and the whole point of the scale is to stop pretending otherwise.
A score is really three questions, not one. How bad is it if this fails. How long can you stand it being down. And how many people can actually fix it. Those usually travel together, but not always. Something can be catastrophic yet survivable for a day. Something else can be only moderately painful but intolerable for ten minutes. Pulling those apart stops you from pouring effort into the thing that is scary but patient while you under-protect the thing that is modest but urgent.
Criticality drifts upward, and almost no one re-rates it. The small tool that started as a three becomes genuinely useful, picks up users, and quietly turns into a seven. The trouble is that it still gets treated, staffed, and backed up like a three. That gap is where small teams get hurt. The fix is cheap. When something crosses a real threshold of use or dependency, re-score it on purpose. Even the lowest tier earns one rule for this reason: somebody other than the person who built it has to know it exists. A system nobody remembers is a system nobody can save.
Set your requirements in bands, not a single line. A single cutoff forces a yes-or-no fight over which side something falls on, and reality does not cooperate. Bands match how risk actually scales. The top tier might call for several people who can genuinely diagnose and repair it, full backups, and a tested way to redeploy fast. The middle might ask for a second trained person and real redundancy. The bottom might ask only for documentation and one other set of eyes. The dials, people, redundancy, and documentation, turn up as the score climbs.
The most valuable thing the scale gives you is not technical. It is that criticality has a budget. If your top tier requires several people who can fix it, and you only have a handful of hands that truly touch systems, then you can afford only so many true tens before your whole bench is committed. That is not an argument for lowering the bar. It is the argument for the whole exercise. When someone wants to crown one more system mission critical, they have to free up people or agree it sits lower. The scale forces that trade into daylight, before the outage instead of after it.
This is also the clearest way to settle build versus buy. A lot of people have been convinced that they can now build their own version of almost anything, and often that is true, you can get something working. But the scale asks a sharper question than whether you can build it. It asks whether you can hold it. Buying looks like it hands the people, the redundancy, the uptime, and the two in the morning call to someone else. It does, but only if that someone actually answers. Buying does not erase the 2am risk, it moves it to a vendor you do not control, and now you are betting that they pick up, that their fix is quick, and that they are still in business next year. For most systems that is a fine trade. For a true ten, where you cannot afford to sit in a support queue while the business waits, that dependency is sometimes the very reason to keep it in house. Building it yourself is more work, and the number of people who understand it usually starts at one, so you have to commit to staffing its band for as long as it lives, or you have quietly created a mission critical service with a single point of knowledge. But the work is yours to control, and sometimes control is the thing you cannot buy. Let the score make the call. A low criticality tool is cheap to build and cheap to lose. A high criticality one is a standing commitment either way, in people if you build it or in trust if you buy it, and the honest question is which of those you can actually keep.
And the things that land below your line are not unprotected. They are accepted risk, written down and agreed to. That distinction is what protects a small team in the room. When a lower-tier system breaks, it was a known trade that was signed off on, not a failure of the people holding everything together.
The scale does not make the work smaller. It makes the work honest. It tells you what is worth protecting, what you can actually hold to that standard, and where to stop. For a lean team, that is not giving up. It is how you stay standing and still have room to build.