Quick note on the Simple Agreement for Future Equity (SAFE)
The SAFE isn’t broken. It’s also not perfect. But it works.
I’ve had quite a few discussions on whether investors should modify the standard Y Combinator (YC) SAFE template. I’m firmly in the don’t modify camp. Then again, I’m not a lawyer—so what do I know about legal documents? Regardless, this is a topic I’ve been meaning to tackle for a while, so I’m going to give it a shot. Good thing it’s not controversial at all…
A bit of context
The SAFE was introduced in 2013 by YC as a simple instrument for early-stage fundraising. The premise is straightforward: download the template (YC actually offers three SAFE templates depending on your fundraising characteristics), fill in the blanks (Investor, Company Name, Valuation Cap, Investment Amount…), sign, and boom—money is wired in a matter of days (or even hours).
The rationale? Startups don’t have the time or resources for complex legal processes to unlock investment, and standardizing terms avoids lengthy negotiations. Also, early-stage investing is highly risky. A lightweight agreement is sufficient, and within a relatively short time, the company will either fail or raise a priced round where the SAFE converts to equity. This should take months—not years.
From pre-money to post-money
The original 2013 SAFE was a pre-money instrument. As SAFEs gained popularity, founders began stacking multiple SAFEs at different valuation caps, which made it a nightmare to calculate investor and founder ownership. Each new SAFE diluted the earlier ones. Anyone who’s run this math knows the pain—and not knowing exactly how much of the company you own isn’t ideal for anyone involved.
To solve this, YC introduced a post-money version in 2018. The major improvement was clarity: investors and founders now know exactly what percentage of the company is being purchased. For example, if an investor puts in $1M at a $10M post-money cap, they know they’re getting 10% of the company. Simple.
But here’s the big tradeoff: in a post-money SAFE, future SAFEs dilute only the founders, not prior SAFE holders. This has led some to say the post-money SAFE is investor-friendly, while the pre-money version is founder-friendly (since future SAFEs dilute both founders and earlier investors). The assumption here is the company has not raised any additional capital before the SAFEs—ownership is fully with the founders.
While that’s technically true, I’d argue the pre-money SAFE was being abused. SAFEs are meant for short-term use—stacking them for years defeats the purpose. Further, companies could issue new SAFEs without informing earlier investors, quietly diluting them.
So… should you modify a SAFE?
If you’ve ever downloaded a SAFE from the YC website, you’ve likely seen the disclaimer urging you not to modify it. And for good reason.
YC’s goal is to standardize the fundraising process, reduce friction, and avoid unnecessary costs. Is the SAFE perfect? No. But it’s good enough in most cases. I usually recommend founders don’t modify it. If there are additional terms to discuss, negotiate them through a Side Letter—YC even provides standard Side Letter templates (which should be adjusted accordingly). Just keep them short, or you’ll miss the point of using a SAFE in the first place.
Why I believe SAFEs shouldn’t be modified
The moment you modify it, it’s no longer a SAFE. Call it whatever you want—Patrick’s SAFE, Fund X’s Not-So-Simple SAFE—but it’s no longer the standardized document it claims to be. You even need to delete the standard disclaimer from YC that says it hasn’t been modified.
Side Letters solve most issues. If something needs to be clarified or added, use a Side Letter. No need to alter the core document.
It keeps things clean for everyone. If every investor signs a different version of the SAFE, that creates chaos. Founders, lawyers, and future investors all have to review each custom agreement.
Mistakes happen. I’ve seen it too many times: someone modifies the SAFE, forgets to update the disclaimer, and no one notices until a problem surfaces down the line. It’s not fun—or simple.
When is it OK to modify a SAFE?
If your fundraising situation is so complex that you feel compelled to modify a SAFE… maybe you shouldn’t be using one.
SAFEs were designed for early-stage fundraising—think Pre-Seed or Seed. If a Series C company is using a SAFE, it will definitely require modifications (and likely a different instrument altogether). At that point, you’re using a SAFE in name only.
Another common request is to add a maturity date, as some investors fear being locked into a SAFE indefinitely if no priced round occurs. A maturity date can create a forcing mechanism—if triggered, it opens up a conversation about converting or extending.
Please avoid
One of the trickiest situations I’ve seen is when a company issues both pre-money and post-money SAFEs. If you're set on modifying a SAFE—fine, we can agree to disagree. But mixing different SAFE structures before a priced round creates major complications when it’s time to convert and calculate ownership. Pre-money SAFEs dilute each other and future investors; post-money SAFEs don’t. So when you try to convert both types at once, you’re stuck juggling conflicting dilution mechanics. The math becomes a mess, and it’s nearly impossible to get to a clean, agreed-upon ownership breakdown without lengthy and confusing negotiations. Avoid it if you can.
Final thoughts
This isn’t meant to be a comprehensive guide—just some reflections I’ve wanted to share. As I said earlier, I’m not a lawyer. But I do think this captures the core of the SAFE debate and why I strongly believe in keeping it simple.
Also, keep in mind that when you bring up a SAFE—whether as a founder or investor—the other side will likely assume you're talking about the standard YC version. If terms are agreed upon, and then you send over a modified SAFE without prior notice, it can create unnecessary friction. If you’re planning to make changes, be upfront early on and explain your rationale—better to have that conversation before things go sideways.