Blog · Growth ·
The Bootstrapper's Guide to Mental Models for Better Decisions
Why the mental models you choose matter more when you can't afford to be wrong — and how to stop using frameworks as a sophisticated way of hiding from the decision.
The Bootstrapper's Guide to Mental Models for Better Decisions
Picture a joiner running a small business out in Kent — call him Alan. Hands like a bag of walnuts, still writes invoices on a pad because "the software takes the piss." He's a composite, not a real person, but the decision in front of him is real enough, because some version of it lands on every bootstrapper's desk eventually: take on a big commercial contract that would double the size of the business overnight, or stay small and keep doing the kitchen extensions that actually pay the mortgage.
He takes the contract. Hires four blokes he barely knows. Six months later he's sleeping four hours a night and two of the new hires have quietly buggered off to a competitor, taking a client list with them. He doesn't go bankrupt. But he comes close enough to taste it, and he won't talk about that year without going a bit grey around the eyes.
Here's the thing though. Everyone tells this story as a cautionary tale about growing too fast. That's the lesson you're supposed to take. Slow down, stay lean, don't bite off more than you can chew. Fine. Except that's not actually what goes wrong in this story, and treating it as the lesson would make the next decision worse, not better.
What goes wrong is that Alan makes a scaling decision using a resource-allocation mental model when the actual problem is a trust model. He's thinking about money, capacity, contracts. He isn't thinking about the fact that hiring people you don't know well is fundamentally a bet on character you can't verify yet. Different problem. Different tool required. He uses a hammer on a screw and then blames the hammer.
This is basically the whole game when you're bootstrapping something. You don't get do-overs the way a funded company does. If you burn the runway, there's no next round. So the mental models you use to make decisions aren't just intellectually interesting, they're the actual mechanism keeping the lights on. I want to walk through a few that matter more than people think, and one in particular that gets abused constantly.
1. Reversible vs irreversible decisions
Jeff Bezos talks about "one-way doors" and "two-way doors," and yes, I know, quoting Bezos in an article about bootstrapping feels a bit like quoting a shark about swimming lessons. But the framework itself holds up regardless of who said it or how much money they now have.
A two-way door decision is one you can walk back through. Try a new pricing model for a month? Two-way door. Fire your only developer and replace them with your cousin who "knows computers"? One-way door, and also possibly a mistake you'll be paying for in therapy.
The failure mode isn't ignoring this distinction. Most people know it exists in theory. The failure mode is treating every decision like it needs the same level of deliberation, which means you either burn weeks agonising over reversible stuff that doesn't matter, or you sprint through irreversible stuff because you're tired of thinking. It's the same test we apply to our own experiments at Adapt Progress Evolve: if a bet can be unwound in a week, it gets decided in an hour.
Alan's contract decision was one-way. Once he'd hired those four guys and taken on that scope, unwinding it would have cost the business's reputation locally. He should have spent three times longer on it than he did. Instead he spent about the same amount of time he'd spend picking a van.
2. Inversion
Charlie Munger's favourite trick, and one of the few mental models that's genuinely as useful as its reputation suggests (most aren't, more on that below). Instead of asking "how do I succeed at this," you ask "how would I guarantee failure," and then you avoid doing that.
It sounds almost too simple to bother writing down. It is simple. That's sort of the point.
For a bootstrapped business, inversion looks like this: instead of "how do we grow revenue 30% this year," ask "what would kill this business in the next twelve months." Usually the answer isn't lack of growth. It's a key client leaving, a founder burning out, cash flow gaps during a slow quarter, or one bad hire poisoning the culture. Notice none of those get solved by growing revenue. They get solved by boring things like diversifying your client base or, I don't know, sleeping more than five hours a night.
3. The map is not the territory
This one gets abused. People love saying "the map is not the territory" at dinner parties because it sounds clever and requires zero follow-up thinking. What it actually means for you, running an actual business with actual invoices, is that your mental model of your business (the spreadsheet, the org chart, the five-year plan) is always a simplification, and simplifications lie by omission.
Your cash flow spreadsheet doesn't know that your best client's business is quietly struggling and might not renew. Your org chart doesn't capture that two of your employees hate each other and it's slowing everything down. The map is useful. It is also, structurally, always wrong in some way you haven't noticed yet.
I'd be cautious of anyone who tells you a framework will give you the full picture. It won't. That's not the framework's job.
Where mental models actually go wrong
Now here's the twist, and it's the bit most articles like this skip because it undermines the whole "frameworks will save you" pitch.
Mental models can become a form of procrastination dressed up as rigour. I've watched founders spend four hours in a "decision matrix" for a choice that a coin flip would have resolved just as well, because doing the analysis feels like progress and making the actual call feels like risk. The framework becomes a security blanket. You're not thinking clearly, you're hiding.
There's a popular idea, thrown around a lot in productivity circles, that having "more mental models" makes you a better thinker, full stop, no caveats. I'm sceptical of that claim in its strong form. Having more tools in a shed doesn't make you a better carpenter if you don't know which one to pick up for the job in front of you, and honestly it can make you worse, because now you've got the option to dither between six frameworks instead of just picking up the saw.
The actual skill isn't accumulating models. It's building the judgment to know, fast, which situation you're in. Reversible or not. Resource problem or trust problem. Genuine complexity or your own fear wearing a complexity costume.
So what do you actually do with this
Three things, and I'll keep it concrete because vague advice is how this genre usually loses people.
- Before any big decision, name the category out loud. Not "should I do this" but "is this reversible, and what kind of problem is this actually." Takes thirty seconds. Saves you from applying the wrong tool entirely, which was Alan's whole issue.
- Set a decision deadline before you start analysing. If it's a two-way door, give yourself an hour, tops. If you're still going in circles after that, you've stopped analysing and started avoiding.
- Write down what would need to be true for this to fail, before you commit. Not as a mood-killer, as a filter. If the failure conditions are things entirely outside your control, that's useful information. If they're things you're already quietly ignoring, that's more useful still.
Run the tape forward on Alan and give him another big contract. The version of him who's learned the lesson doesn't reach for a better framework — he spends two weeks just getting to know the subcontractors before signing anything, and treats the decision explicitly as a trust problem rather than a capacity one. Whether that particular deal pays off is beside the point. He's finally solving the problem that's actually in front of him.
That's the real skill nobody sells you a course on: not collecting more models, just getting quicker and more honest about which one applies. Everything else is decoration.
Drafted by the Adapt Progress Evolve agent fleet; edited and approved by a human.