Raise enough to reach your next meaningful milestone — with 18 to 24 months of runway and a 3 to 6 month buffer beyond what your model shows. The right number comes from working backwards from a milestone, not forward from a round size.
Why this question matters more than most
Raise too little and you run out of runway before you've proven your hypothesis — forcing you to raise again from a weak position, when you're almost out of cash, with leverage working against you. Raise too much and you over-dilute at the wrong valuation, set return expectations you may not be able to meet, and create pressure to deploy capital in ways that don't match where you actually are.
The goal is precision: enough to get somewhere worth going, without giving away more than you need to in order to get there.
How to calculate what you actually need
Start with your next milestone — not your long-term vision. What does the company need to demonstrate in order to raise its next round? Then work backwards:
- Define the milestone. Be specific. "Raise a Series A" is not a milestone. "Reach $500K ARR with three paying enterprise customers and a functioning sales motion" is a milestone.
- Estimate the timeline. How long will it realistically take to reach that milestone? Be honest. First-time founders consistently underestimate this by 30 to 50 percent.
- Model your monthly burn. Include salaries, employer taxes, benefits, software, office, contractors, and anything else you'll need to spend to execute. Do not skip employer taxes — they add 15 to 20 percent on top of gross salary.
- Add a buffer. Plan for 3 to 6 months beyond your milestone. The fundraising process itself takes time — typically 3 to 6 months from first conversation to money in the bank. You'll be burning while you raise.
- Add transaction costs. Legal fees, accounting, and closing costs typically run $15,000 to $40,000 for a seed round.
The formula: (Months to milestone + buffer months) × monthly burn + transaction costs = target raise
Common mistakes that throw off the number
Raising "as much as possible." This isn't a strategy — it's a hedge against not knowing what you need. Investors can tell the difference, and it invites hard questions about why you need so much and what you'll do with it.
Anchoring to a round label. "We're raising a $1.5M pre-seed" is a social reference point, not a financial one. If your model says you need $800K, raise $800K. Round sizes should follow your plan, not the other way around.
Underestimating burn. The most common version is building a hiring plan that ignores what it actually costs to employ someone — taxes, benefits, equipment, and onboarding time before they're productive.
Forgetting the fundraising period. If it takes you 4 months to close a round and you're burning $50K/month, that's $200K of runway consumed while you're not building. Model this explicitly.
Ignoring dilution math. At $500K on a $2M pre-money valuation, you're giving up 20%. At $500K on a $4M pre-money, you're giving up 11%. The amount you raise and the terms you raise it on are inseparable — model both together.
A simple example
A two-person software team wants to build and validate an MVP. Their goal: reach 10 paying customers with a clear retention signal — enough to raise a seed round.
- Timeline to MVP: 5 months. Timeline to 10 customers: 5 more months. Total: 10 months.
- Monthly burn: $30K (two founder salaries, tools, AWS, some marketing).
- Buffer: 4 months.
- Fundraising period cost: factored into buffer.
- Transaction costs: $20K.
- Total: 14 months × $30K + $20K = $440K.
If they're raising at a $3M pre-money, that's roughly 13% dilution. If they raise $500K instead of $440K to round up, that's still a defensible ask with clear rationale.
When to get outside help
Most founders can do this math themselves once they understand the framework. But consider getting support if: you're modeling complex scenarios with multiple hires and dependencies; you're not sure what milestone matters to investors at your stage; you've received term sheets and need to evaluate the dilution implications; or your cap table already has multiple SAFEs stacking at different caps and the conversion math is getting complicated.