← Perspectives

· Hannah Wairua

What We Look For in Seed-Stage EdTech Diligence

After two years and ten investments, we've developed a working thesis on what separates EdTech companies that scale from those that stall at pilot-stage.

Two years and ten investments into running a seed-stage EdTech fund, we've developed a working framework for what separates companies that will scale from those that will stall at pilot. It's not primarily about technology quality, though technology quality matters. It's about a specific configuration of founder-market understanding, product-market evidence, and go-to-market clarity that only becomes legible when you've seen the patterns repeat enough times.

The first question we ask is whether the founder can describe the exact adoption pathway from first contact to institutional budget. Not from first contact to pilot — pilots are relatively easy to get in education, because curious, change-oriented educators are not hard to find, and institutional risk tolerance for a no-cost or low-cost trial is higher than in most enterprise markets. The hard question is what happens after a successful pilot. Does the school have a budget line where this product fits? Who approves the renewal? Is it a principal decision, a board decision, a cluster or network decision? What metric does that decision-maker use to evaluate whether the pilot was successful? Founders who can answer these questions specifically, based on actual conversations with the decision-makers in their pilot schools, have done the customer discovery that matters. Founders who can describe a successful pilot in terms of teacher satisfaction and student engagement data, but can't describe the conversion pathway to institutional budget, are in a more fragile position than the pilot results suggest.

The second question is about evidence of genuine teacher utility — not teacher satisfaction, which is relatively easy to generate with a well-designed product, but observable changes in teacher behaviour that demonstrate the product has become embedded in workflow. A teacher who is satisfied with a product but would not change their practice if it disappeared is giving you NPS data, not retention data. The teachers who are genuinely dependent on a tool — who structure lesson planning around it, who notice its absence when the internet goes down, who recommend it to colleagues without being asked — are showing you something about product-market fit that survey data can't capture. We ask founders to describe specific teacher behaviours they've observed that indicate this level of adoption. Founders who have been close enough to their users to have those stories have usually been doing the right kind of qualitative research.

We should acknowledge what we don't weight heavily enough at seed stage. We do not weight current revenue as heavily as investors in other sectors do, because the institutional EdTech sales cycle is long enough that a genuinely good seed-stage product in active pilot with two or three institutional partners is often pre-revenue or minimal-revenue in ways that would be concerning in a SaaS business targeting more standard enterprise markets. We've seen at least two companies in our network that were passed over by generalist seed investors who applied standard SaaS traction metrics and missed that the institutional adoption dynamics in education simply don't generate early revenue on the same timeline. What we weight instead is the quality of the institutional relationships — are these genuinely enthusiastic early partners who are actively participating in product development, or are they polite recipients of a free tool who will not renew if asked to pay?

The third filter is technical architecture, and specifically whether the product has been built with the data model and API design that institutional buyers will require for integration and compliance. This is James's domain in our diligence process, and the issues we find here are not usually about engineering quality in the narrow sense — most founders in this cohort are technically strong. The issues are about architectural decisions made early in the product's development that create compliance debt: data storage choices that don't align with NZ Privacy Act data residency expectations, assessment item schemas that can't map to NZQA standard references, LTI integration implementations that are incomplete or non-standard. None of these are fatal at seed stage if the team understands them clearly and has a credible plan to address them before they become blockers to institutional scale. What concerns us is when a founder either doesn't know the compliance requirements or dismisses them as something to sort out later. That posture almost always produces a more expensive problem at the Series A stage.