After the Realm acquisition closed, I spent time as an advisor — helping a small number of tier-one VCs evaluate deals on the technical and founding-team side of their diligence. I'd sit in on pitches. I'd do technical architecture reviews. I'd be the person who asked the hard questions about whether the engineering team had actually solved the problem they claimed to have solved.
From that position — having pitched VCs as a founder and then being the one evaluating — I started to notice a pattern.
When the traditional signals weren't there (revenue too early, market validation still nascent, team without a specific exit in the pedigree), the investors who were right — the ones whose early-stage bets kept working out — tended to converge on the same three questions. They didn't always ask them directly. But they were triangulating on the same three underlying things.
This is pattern recognition, not magic. Here's what they're actually looking for.
Question One: Has this founder already encountered the thing that should have killed the project?
The clearest signal of an unstoppable founder mindset isn't ambition or intensity. Those are table stakes. The signal is evidence of having hit the hard thing specific to this project — the setback, the technical dead end, the customer segment that turned out not to exist, the co-founder departure — and having continued anyway, with a clearer view of the problem rather than a more optimistic view of the solution.
The distinction matters. Founders who continue after a hard setback because they're still convinced the original thesis was right haven't learned anything. Founders who continue because the setback clarified something — revealed a different customer, exposed a better architectural approach, proved which assumptions were wrong — these are the ones who tend to solve the problem eventually.
In a pitch, this comes out in how founders describe what's changed since they started. The specific language to listen for: founders who describe pivots as "we learned X, which led us to Y" are showing evidence of the right pattern. Founders who describe pivots as "we tried X, it didn't work, so now we're trying Y" are describing trial and error without demonstrating that the error was informative.
The one I keep coming back to from our own experience at Realm was the synchronization problem. We had originally scoped Realm as a local persistence layer — a better SQLite. Then we built a sync feature as an extension. Early users who tested the sync prototype told us, with some consistency, that the sync was broken in ways that mattered in production. We could have interpreted that as "sync is too hard, let's focus on the storage layer." Instead, what the feedback actually said — when we stopped defending our implementation and started listening to the failure modes — was that the sync problem was the real problem worth solving, and that our storage architecture was uniquely positioned to solve it because of the data format decisions we'd already made. The setback clarified the thesis. It didn't discourage it. The companies that come out of hard setbacks with a cleaner model of what they're building are usually the ones that find the real product eventually. The ones that come out having survived the setback but still defending the original thesis tend to hit the same wall again.
Question Two: Is this a genuinely hard problem, or a hard-ish problem?
The distinction sounds philosophical. The investment implications are concrete.
A hard problem creates a durable moat for whoever solves it first, because the difficulty of the problem deters replication. A hard-ish problem gets solved by the first mover and then immediately replicated by everyone with resources.
The test for whether a problem is genuinely hard: would a well-funded competitor with access to the best engineering talent take more than eighteen months to build a version that's competitive with yours? If the answer is yes, the problem is hard. If the answer is no — if it's fundamentally a matter of capital, execution time, and engineering quality — the problem is hard-ish.
Most software problems are hard-ish. The ones that are genuinely hard tend to share common characteristics: they involve a technical insight that isn't publicly available (most ML research is, but most applied implementations of that research are not), they require a type of domain knowledge that takes years to accumulate and can't be hired quickly, or they involve a network effect that makes the first-mover position self-reinforcing.
Realm's zero-copy storage engine was a hard technical problem — specifically, designing a data format where on-disk representation and in-memory representation were identical, while maintaining MVCC without traditional locking. The implementation took over a year by a small team of expert engineers. A well-funded competitor would have needed at minimum twelve months to replicate it, and likely longer, because the specific insight about data format identity wasn't obvious from the outside.
That hardness was a real moat. It's why the performance gap between Realm and SQLite was 80x rather than 2x — and why a 2x improvement wouldn't have been interesting enough to build a company around.
Question Three: Why now?
The hardest question in early-stage evaluation, because "why now" requires a model of the future that can't be directly verified.
But the investors who are right consistently at early stages aren't guessing at the answer. They're looking for founders who have a specific, well-evidenced model of what has changed — technically, regulatory, in distribution, in customer psychology — that makes this problem solvable now when it wasn't solvable two years ago.
The strongest version of "why now" isn't a technology trend. It's a convergence of specific changes:
At YC S11, I watched Realm's "why now" evolve over the batch. The answer at the beginning was "smartphones are getting powerful enough to run a real database locally." That was true but incomplete. The better answer, which took months to articulate clearly, was: "Smartphones are powerful enough to run a real database locally, app complexity has increased to the point where SQLite's threading model creates real bugs, and developers have enough experience with mobile to be frustrated with the current tooling rather than just accepting it." The third element — developer frustration at a specific level of experience — was the inflection point that SQLite's raw market size didn't capture.
"Why now" answers that depend on a single factor — just the technology trend, just the regulatory change, just the market size — are usually incomplete. The real inflection points are usually convergences of three or four factors that combine to make the moment specifically different from two years ago.
Before your next pitch, run the self-audit against these three questions directly.
Can you point to a specific hard thing you've already encountered, describe what you learned from it, and explain why that learning changes your trajectory? If you're describing a path that hasn't hit its hard thing yet, experienced investors will be wondering when it will and whether you'll survive it.
Can you explain why your problem is genuinely hard — not hard to build, but hard to replicate — in terms that would survive thirty minutes of technical questioning? If the hardness depends on execution advantages you haven't built yet, the moat isn't real yet.
Can you describe three specific factors that have converged to make now different from two years ago? Not one trend. Three specific, evidenced changes and why their combination makes the moment right for this company.
These aren't the only questions that matter in a fundraise. But they're the questions that the investors who are right early tend to be triangulating on. Getting clear answers to them before you start pitching is worth more than most pitch prep I've seen.
Pattern recognition, not magic.