You have $2,000 left in the bank, four months of runway, and a product idea you're convinced will work. Everyone tells you to "run lean experiments." Nobody tells you that most of the experimentation advice out there was written for people with a credit card limit they never have to think about.
The truth is that lean startup experimentation for resource-constrained founders is a fundamentally different discipline from what Eric Ries described. Ries built his framework inside a venture-backed company with a team, a salary, and room to be patient. When your constraint is real—when the constraint is survival—the playbook has to change.
I learned this the hard way after watching three founder friends burn through their savings running "proper" experiments they couldn't afford. So let's talk about what actually works when you have more conviction than cash.
Key Takeaways
- Resource-constrained experimentation is about speed-to-signal, not statistical rigor—you need directional truth fast, not a journal-ready result
- The cheapest valid experiment is almost always a conversation, a landing page, or a manual service delivered by hand
- Your real budget is time and attention, not money—track it the same way you'd track burn rate
- Most "lean" frameworks assume free labor. Own that assumption explicitly or it will eat you alive
- Kill criteria set before the experiment runs are the only thing standing between you and sunk-cost delusion
- One strong signal beats five weak ones. Stop hoarding data you can't act on
What "resource constrained" actually means (and why nobody defines it)
Search for lean experimentation advice and you'll find endless posts about MVPs, pivot-or-persevere, and validated learning. What you won't find is anyone willing to draw a line and say: below this threshold, the standard playbook breaks.
So let me draw it.
You're resource-constrained if you cannot afford to run an experiment that produces no revenue and no learning for 90 days. That's the honest definition. It's not about a specific dollar figure—it's about whether a failed experiment ends your company or just annoys your investors.
Three types of constrained founders, three different constraints
Not all scarcity looks the same. I've been each of these at different points, and the tactics that work for one will actively hurt another.
- The solo bootstrapper — no team, no salary, maybe a day job. Your constraint is hours. You can spend money you can't spend attention.
- The pre-seed team of two or three — enough runway for maybe six months. Your constraint is calendar time. You have hands but no slack.
- The emerging-market operator — payment infrastructure is unreliable, customers have low purchasing power, but your cost base is also low. Your constraint is distribution, not capital.
Which one are you? Answer honestly. The founder who says "all three" is the founder who runs no experiments at all, because every tactic looks too expensive from one angle or another.
Why the generic advice keeps failing you
Here's the thing that took me embarrassingly long to internalize. Most lean startup case studies quietly assume free labor. "Run a concierge MVP" sounds cheap until you realize it means you personally fulfilling orders for 40 hours a week while also doing sales, support, and product. That's not cheap. That's a second job you're not being paid for.
The frameworks aren't wrong. They're just priced for someone else.
The cheapest valid experiments you can run this week
A "valid" experiment is one where the result changes what you do next. That's it. It doesn't need a control group. It doesn't need significance testing. It needs to be capable of telling you to stop.
Here are the four I keep coming back to, ranked by how little they cost in both money and time.
Customer conversations, done properly
Ten real conversations will teach you more than a hundred survey responses, and they cost you only the time to find the people. The trick is that most founders run these badly—they pitch, then interpret polite nodding as validation.
Don't pitch. Ask what the person currently does about the problem you think you solve. If they describe a workaround, ask what it costs them. If they say "nothing, it's fine," you have your answer and you've saved yourself six months.
The landing page smoke test
A single page, a clear promise, a button that says something like "Join the waitlist" or better, "Reserve your spot for $10." You can build this in an afternoon. The point isn't the page—it's the click.
Email capture is a weak signal. Payment intent is a strong one. If your constrained budget only allows one experiment, make it this one, and make the ask as close to real money as you can ethically get away with.
Concierge and Wizard of Oz
Deliver the service manually before you build anything. If you're building software that categorizes expense reports, sit down and categorize them yourself for three clients. If you're building a marketplace, play both sides with a spreadsheet and a phone.
This feels humiliating. It's supposed to. It's also the single fastest way to learn what the product actually needs to do, because you'll experience every failure point with your own hands.
Pre-sales before you build
Ask five people to pay you now, for something that doesn't exist yet, with a clear refund promise. Two or more saying yes is a signal. Zero is also a signal—arguably the most useful one you'll ever get.
Comparing experiment types when money is the binding constraint
Not every experiment fits every constraint. Here's how the main options stack up when your budget line is the thing that matters most.
| Experiment | Cash cost | Time cost | Signal strength | Best for |
|---|---|---|---|---|
| Customer interviews | Near zero | High | Medium | Problem validation |
| Landing page + payment ask | Low | Low | High | Demand validation |
| Concierge MVP | Near zero | Very high | High | Solution design |
| Wizard of Oz | Near zero | High | High | Feature prioritization |
| Ad-based smoke test | Medium | Low | Low | Message testing |
| Full MVP build | High | Very high | High | Only after prior validation |
Notice that the two highest-signal, lowest-cost options both require your direct time. That's the trade you're making. You are substituting your own labor for capital, and pretending otherwise is how founders end up with a half-built product and an empty bank account.
Setting kill criteria before you start (the part everyone skips)
Write down, before the experiment runs, what result would make you abandon the idea. Put it in a note dated today. This is the only defense you have against the sunk-cost spiral that eats constrained founders alive.
A concrete example: "If fewer than 3 of 20 interviewed users describe this as a top-three pain, I stop." That's a kill criterion. "I'll see how it feels" is not.
The reason this matters more for you than for a funded founder is simple arithmetic. They can absorb a wrong turn. You cannot afford two. Every week spent on a dead idea is a week of runway you don't get back.
The constraint you keep forgetting about
Money is the visible constraint. Attention is the invisible one.
I once watched a founder spend six weeks building an analytics dashboard for her own experiments—measuring everything, deciding nothing. The dashboard was beautiful. The company ran out of money before she acted on a single chart. She had optimized for looking rigorous while the actual resource—her decision-making capacity—sat idle.
Your scarcest asset is not cash. It's the number of clear decisions you can make per month before your judgment degrades. Guard that number the way you'd guard your last thousand dollars.
So here's the question I'd leave you with: if you had to run exactly one experiment next week, and it had to be capable of killing your idea, what would it be? If you can't answer that in thirty seconds, you don't have a resource problem. You have a clarity problem—and no amount of lean methodology will fix that for you.
