Ahmad Sadeddin, founder of Corgea: you don't need to raise (much) to find PMF
Ahmad Sadeddin, founder of Corgea, on why raising more than $2.5M to reach PMF is usually a mistake, why he skips design partnerships entirely in favor of collecting a wall of "no"s, and the customer conversation so good a rival tried sending a board member to win the deal back.
Ahmad Sadeddin is the founder and CEO of Corgea, which builds security tooling to find, triage, and fix insecure code. A LinkedIn post he wrote arguing that startups don't need to raise much to find product-market fit got a lot of pushback — so we dug into why he believes it, what Corgea actually did to find PMF, why he deliberately skips the standard design-partnership advice, and how the AI coding wave ended up validating a bet he made back in 2023.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You posted that you don't need more than $2.5 million to reach product-market fit, and it got a lot of pushback. Why do you believe that?
Raising a lot of money has become a vanity metric — people think it shows market validation, but it optimizes for the wrong thing. The real purpose of a seed-stage startup is to find PMF, not to fundraise; fundraising is a cost of doing business, and it takes a lot of time and energy away from the actual goal. It also incentivizes bad behavior — overhiring, throwing bodies at the problem. I remember one of our YC partners, Diana, telling us: if you don't need more money, don't take it, because money doesn't solve product-market fit and it doesn't solve your go-to-market strategy — you and your team have to solve those. People forget Stripe, Airbnb, and Uber raised much smaller seed rounds than today's standard, took worse dilution, and had a harder job — Airbnb was running physical servers before cloud computing existed. Paul Graham has talked about this too: you want to surprise people with how lean you are, because that's a stronger signal of product-market fit than the round size. A small team achieving something visceral with a great go-to-market shows real strength — I've seen too many startups raise a huge round, hire an army of salespeople they can't feed because the product or go-to-market is weak, and end up celebrating a fire-sale acquisition as a win.
What does 'lean' actually mean in headcount and runway terms, and what happens when it goes wrong?
It depends a lot on your industry — hardware and biotech are genuinely different and should raise accordingly. But for most software companies, $2 to $4 million should give you roughly two to two-and-a-half years of runway to figure things out, even hiring at Bay Area rates. I think you can accomplish a lot with a team of three to five people, maybe stretching to under ten — above that, I start questioning whether you're overhiring. I've seen startups that just came out of stealth hiring a chief of staff and an ops person, starting SOC 2 and ISO 27001 before they even have customers — that's putting the cart before the horse. We punted on SOC 2 until it became a hard requirement for actual deals. I've watched a competitor raise somewhere between $50 and $80 million, net only $4 to $7 million in revenue, run out of money, and get acquired for less than half of what investors put in — and while the company celebrated the acquisition publicly, their investors told me privately it was such a bad outcome they don't want to invest in that space again.
You pivoted four months into YC. What happened, and how did being small make that possible?
We started building a product we didn't actually think had a big enough advantage in the market, and four months into YC, we pivoted — the best decision we ever made, and we turned out to be completely right about the new direction. We could only do that because we were a very small team, three or four people — I could put everyone in a room and say this isn't working, here's an idea, and just go. We started building a wedge and navigating through customer conversations, and every time we shipped something, we noticed the probability of a customer buying kept increasing. We sold our first customers as a four-person company, and only grew headcount in a way that was justified by revenue and increasingly strong signs of PMF. I don't think there's a hard headcount number — it's really about what it takes to hit your Series A goals: early signs of PMF, a reproducible go-to-market motion, and customers who are actually alive and succeeding with your product.
The standard advice in security and dev tools is to form design partnerships early. You didn't. Why?
I'd rather get a no than a maybe from customers. With a design partnership, you end up giving away work for free for months while a customer helps you design the product, but the quality of what you build ends up dictated by the quality of that one design partner, and you can lock yourself into a cohort that isn't representative of good customers long-term. Our version was to just go talk to a lot of people and collect a lot of nos to figure out the systematic pattern in the market — I've probably spoken to hundreds of security teams at this point. We went for the jugular: are you going to buy this or not? If no, why not? That wealth of "no, because we don't have budget" or "no, because I don't see the business value" was incredibly useful data. Over time the nos started turning into yeses — no, no, no, no, yes, yes, no, yes, yes, trending up — and that trend is what told us we were closing in on something real.
How did you actually figure out that AppSec tooling was underserved?
Complaints. I started asking people to name one security tool they deeply love, the way a developer might say they love Supabase or PostHog or Cursor, and in AppSec, that tool just doesn't exist. I have a slide in one of our decks: fifty reasons people don't like their AppSec tools, and we counted them all. Part of the problem is structural — there's roughly a 1-to-100 or 1-to-200 ratio of AppSec engineers to software engineers, so two or three people are trying to support a hundred developers each, on top of compliance work, pen tests, and constant new threats coming out of nowhere. Development has bad weeks; AppSec has no stability at all. As we kept pulling on that thread, we found more and more systematic failures that the tools people did rely on weren't actually resolving at the root. One rule I use: the majority of your first customer meetings should convert into a pilot — I'd say 60 to 80% within two meetings is a strong sign you've built something people find viscerally important.
You've talked about a '10x better' bar and shipping things half-baked on purpose. How does that work?
We kept asking ourselves: is this 10x better than what the market has today? We started at maybe 2x, then 3x, then 5x, chipping away at the problem until it hit 10x and customers converted — though some converted at 5x already. I tell customers this is the worst version of the product they'll ever use, because we keep digging in further. Sometimes we'll tell a customer straight up that a feature is half-baked and ask them to try it anyway, because nobody else in the market has tried this yet and we want their early feedback before investing further. Customers are fine with that — they'll say just give me the version and I'll give you my honest opinion. It's the Reid Hoffman line: if you're not embarrassed by your first version, you shipped too late.
How much of your timing was luck versus insight, given how the AI wave has played out?
The number one rule is making sure you have optionality — you can't predict the market or predict that you'll get PMF, you just follow a hunch. We were still in discovery through most of 2023 and early 2024, and even once we pivoted into what we do now, nothing was clicking immediately, though we saw good signs. By 2025, everything worked — we started growing fast month over month on a lean team. But AI adoption was also genuinely in our favor: GPT-3.5 to GPT-4 happened in 2023, and once GPT-4 landed, enterprises started actually testing it seriously. 2025 was the year vibe coding really took off, and that helped us directly — if developers are becoming more productive writing code with AI, security has to become more productive securing that code too. We survived long enough because we didn't burn through a lot of money and had a strong conviction, formed in 2023, that AI-generated code was going to make up a large share of codebases. We could have been completely wrong, and the market could have taken three more years to catch up, which would have run us out of money — but throughout, we just kept trying to sell what we had, got a no, tried something else, got a no, and kept going until the yeses started.
How do you decide whether to build something a specific customer is asking for, or say no?
There's a story from Coupa, where I used to work, about ending their relationship with Subway, who was their biggest customer at the time, because Coupa couldn't deliver what Subway wanted and didn't believe it was the right pattern for the rest of the industry either — so they walked away from their biggest account rather than let one customer bend the product in the wrong direction. We tell customers no too — just last week, someone asked for a feature and I told them we won't build it that way for them specifically, because it's our job to be custodians of what good practice looks like. Product management is about spotting patterns across the market and building for best practice, not for one account's specific process. The question I ask is: is this customer doing something wrong and trying to bend the tool to a bad process, or are they onto something that could scale to a real chunk of our customer base? That comes down to pattern recognition built from a lot of customer conversations and a decent memory for what people have told you over time.
You've said startups are purely a mind and execution game. What do you mean by that?
Companies die by suicide, not by competition — you burn too much money too fast, make bad decisions under runway pressure, and end up in what Paul Graham calls the fatal pinch, where you don't realize you're about to die until you no longer have enough runway left to pivot. The quality of a founder's mindset really matters — you have to be honest with yourself and your team, and kill your ego. I came in on my third startup thinking I'd crush it, and got humbled fast watching 26-year-olds at YC outperform me. The lows are genuinely low — we went through pivot hell, and it erodes your confidence. What got me through was an amazing support system and just deciding to keep executing regardless. You have to be like a shark that needs to keep moving to survive — stop, and you'll never reach early signs of PMF or go-to-market fit. You can ignore every piece of startup advice out there and still succeed, or follow all of it and still fail — the only real substitute is having a huge number of conversations and executing as fast as possible on what you learn from them. Even a no is valuable: I'd always rather someone tell me no and why, than string me along with a maybe.
Links & references
This episode is brought to you by WorkOS.