What is a Minimum Viable Company, and how do you define yours?
The short answer
A Minimum Viable Company (MVC) is the smallest version of your business that still serves customers and meets its core obligations during a severe disruption. You define it per critical service: the minimum volume, how long it must hold, the workarounds that deliver it, and the technology that must come back first to support it.
"Switch to manual." What does manual mean?
A key account calls the CEO during an outage. The CEO asks what the plan says. The plan says "switch to manual." Nobody in the room knows what manual means, which orders it covers, or how long it lasts.
That line sits in a lot of continuity plans. It describes an intention, with no volume, owner or duration attached. The Minimum Viable Company closes that gap: it states, in numbers, what the business must keep delivering while technology is down, and what that takes. Some teams call the same idea minimum viable operations. ISO 22301 calls it the minimum business continuity objective.
Define the minimum in numbers
Take a company that receives and ships customer orders. On a normal day it handles 120 orders. Thirty of them need same-day dispatch. After looking at customer consequences and commitments, the business agrees that the other orders can wait up to three days.
That gives you a minimum service level you can plan against: 30 same-day orders a day, for up to three days. Compare that with "keep order processing running." Only the first version tells IT, operations and suppliers what they must deliver.
In financial services, the same thinking sits behind impact tolerances. The minimum describes what you keep running to stay inside them.
Work backwards to what the minimum needs
Now trace what those 30 orders need. You have to receive them, identify them, allocate stock, pick them and arrange delivery. A smaller volume still needs most of the supporting services. The carrier connection doesn't become optional because you're shipping fewer parcels.
This is where workarounds get tested on paper first. Someone suggests processing the priority orders manually. Before you count on that, ask where the stock information comes from. In many companies it lives in the same environment that just went down. Manual processing only works if that information is independently accessible, protected, and has a way to record stock movements during the outage.
Check whether you can sustain it
Suppose the manual fallback handles 40 orders a day. That covers the 30 priority orders, as long as the team has the information and access it needs.
It also leaves 80 orders building up every day. After three days, 240 orders are waiting, assuming steady arrivals and no cancellations. Restoring normal capacity of 120 a day won't clear them, because new orders keep arriving at the same rate. IT can finish its recovery while operations still needs extra people and a way to reconcile the manual records.
Check the people side too. If the same team leads appear in three recovery procedures, they don't have three times the capacity.
Connect the minimum to IT recovery
The minimum and the recovery sequence have to describe the same service. Once the business has agreed the minimum, IT knows what to recover first, at what capacity and by when.
If the minimum can't be supported with today's capabilities, put that shortfall in front of someone who can decide: fund the fix, change the target, or accept the exposure explicitly.
A practical way to begin
- Pick one critical service and state its normal volume in numbers.
- Agree with the business the minimum that must continue, and how long everything else can wait.
- Define the workaround that delivers the minimum, and list the information, people and systems it needs.
- Calculate the backlog that builds up, and how long it takes to clear after recovery.
- Try the workaround with the people who would run it, for at least one full shift.
How we do this in resimate
In resimate, you define the Minimum Viable Company for each disruption scenario: which services must keep running, at what level, and with which workarounds. resimate then builds the recovery sequence from the real dependencies behind that minimum, service providers included. When a dependency changes, continuity plans flag the workarounds that are now missing. Teams go live in 4 to 6 weeks, on the data they already have.