Article
EdTech Only Works When Both Sides Build for It: A Note to the Schools That Buy and the Startups That Build
A failed EdTech rollout usually leaves two people holding two different stories.
The school leader is fairly sure the tool did not work. The founder is fairly sure the school never really implemented it. Both are partly right, and both walk away and keep buying and building exactly the way they did before, because neither can quite see the half the other is standing on. I want to set those two chairs next to each other, because I have sat in both, and the view only makes sense once you have.
If you are the one buying, the scene is familiar. A tool that looked perfect on paper went quietly nowhere. And none of the signals were hollow. The evidence was real. The demo earned its applause. That pilot in someone else's school genuinely worked, and the tool itself was, in all likelihood, a good one. You bought the licenses, ran the training day, and a term later it had still faded into the pile of things people technically have access to and rarely open. The reflex afterward is to decide the tool did not work, but that is seldom the honest explanation.
If you are the one building, you have stood on the other side of that same window. You watched a product you believed in, one with real evidence behind it, land in a school and slowly go dark, and from your seat the reasons were genuinely hard to see. You shipped something good. It still did not take. And the temptation is to decide the school just was not ready, which is true and also not the end of the story.
A recent paper in Smart Learning Environments makes the case that these are not two separate problems. They are one problem seen from two ends. A strong product with real evidence still does not add up to an automatic result in a given building. The tool may well have been fine, and the school may well have been capable, and the thing that failed was the fit between them, which was nobody's job to check.
I have been the teacher handed a tool and told to make it work, and later the one further up the chain weighing which tools a school should adopt and how to roll them out. Eventually I went on to build EdTech myself, sitting at the other end of that same decision. The view from the build side taught me something I wish I had known as a buyer, and the view from the classroom taught me something I wish more builders carried. Most of this piece is me trying to hand each side the other's half.
What the research actually found
The paper, Evaluating EdTech Viability: A Consolidated Benchmark for Implementation, by Natalia Kucirkova, Athina Kardiakou, Olav Schewe, PhD , and Nicola Pitchford , starts from a pattern that should sound familiar on both sides of the table. Big, well-funded programs keep failing for reasons that have nothing to do with the quality of the technology. One Laptop per Child put devices in millions of hands and still never moved the outcomes it promised, partly because teacher training and ministry buy-in were never secured. Turkey's FATIH project wired classrooms across the whole country, then ran into teachers who were not ready and policy that did not line up. South African ICT programs met infrastructure gaps in rural schools that no one had audited before the rollout. The tools were not the problem. The ground they landed on was.
The authors give that ground a name: viability. They define it as the extent to which an educational environment is actually prepared to take in and make good use of a particular tool. The important word is environment. Viability is not a quality of the software. It is a quality of the relationship between the tool and the place it lands. The same app can be a great fit in one school and a poor one in the school next door. There is no such thing as a good tool in the abstract. There is only a good tool here, with these teachers, this budget, this network, this curriculum, or there is not.
They did not invent the dimensions out of thin air. The authors reviewed eleven existing evaluation frameworks, found more than thirty scattered aspects of readiness spread across them, and consolidated those into four dimensions, each paired with a plain capability and scored on a rubric that runs from Poor to Excellent. Stripped of the jargon, these are the four places a rollout quietly dies, and each one has a buyer's side and a builder's side.
Technical, which the paper calls adaptability. On the surface this is systems that do not talk to each other and infrastructure nobody audited before buying, the platform that assumes a connection a building cannot promise on a normal Tuesday, or that will not speak to the tools already in use. Underneath, the paper measures it in concrete ways: whether the system holds up as more users come online without crashing or slowing, whether it is genuinely interoperable and secure, how fast it keeps pace when a curriculum or policy changes, and the unglamorous longevity questions of how often it is updated, how long the software stays supported before it goes obsolete, and how many years the devices last. It also takes language seriously. The top rating is reserved for tools available in multiple localised languages in both text and audio, not just text, and for tools that stay reliable across rural, urban, and semi-rural settings, including low-bandwidth and offline use.
Economic, which the paper calls efficiency. The surface version is the real cost of ownership that surfaces after the contract is signed. The paper is unusually specific about which lines tend to get missed: software licences priced per student and per teacher, hardware unit cost and depreciation over its lifespan, one-time setup that can include network configuration and, in some places, electricity or solar upgrades where the grid is unreliable, recurring licensing renewals, ongoing maintenance and support, and connectivity and data costs month after month. Its blunt point is that price and cost are not the same thing, and that what is affordable in one district can be prohibitive in another. It recommends pricing the whole picture at procurement and revisiting it at every renewal.
Human, which the paper calls capability. The surface version is teachers handed a dashboard with no training or time to use it. The paper measures this as a chain, not a single training day: ease of use, such as how long it takes to complete core tasks and how often people hit errors; onboarding success, meaning how long until a new user is genuinely competent and how many need repeat sessions; adoption, the share of intended users who are actually active and whether that use is sustained rather than spiking at launch and fading; and the quality of the feedback loop between the provider and the teachers using it. Strong human viability looks like embedded, ongoing professional development and leadership that actively drives adoption.
System, which the paper calls capacity. The surface version is tools running as isolated islands, with no governance or curriculum alignment behind them, where no one owns the rollout and the tool drifts away the moment its champion leaves. This turned out to be the dimension frameworks mention most. When the authors counted the recurring themes, governance, funding, budgeting, leadership, vision, and decision-making were the most common words across the whole field. In practice it measures whether there is a formal EdTech strategy, a named coordinator with clear responsibilities, alignment with institutional priorities, monitoring systems that feed real data back into decisions, a working helpdesk, and genuine interoperability with existing systems. It is the least visible dimension in a sales meeting and often the one that decides whether anything survives the first year.
The authors turn all of this into a rubric that scores each dimension from Poor to Excellent, so a tool can be rated in a specific context rather than argued about in the abstract. And that score is not the end of the exercise. It feeds directly into the part of the paper that reframes the whole decision.
The math that puts both sides on the same number
Here is the move I keep coming back to, and it is the one that turns two adversaries into two partners. The authors treat viability as a multiplier on impact, not a separate grade off to the side.
Adjusted Score = Impact Score x Viability Score
Both run from 0 to 1. The math could not be simpler, and the implication is hard to unsee once you have it.
Picture an advanced AI maths platform with a perfect impact score of 1.0, earned in a well-resourced London trial. Drop it into a school with patchy power and no teacher training, where readiness sits around 0.2, and its realisable impact falls to 0.2. The evidence was not wrong. It just described a different world. Now picture a plain little app with a more modest 0.6 impact that happens to be free, works offline, and maps neatly onto the local curriculum, giving it a readiness of 1.0. It lands at 0.6. In that setting, the less impressive tool comes out ahead, and the formula says so plainly.
A readiness score near zero will quietly cancel out almost any impact score in front of it. Read that from the buyer's chair and it says the leverage you have been hunting for in the catalogue actually sits in your own environment. Read it from the builder's chair and it says the evidence you worked so hard to earn is being thrown away at the door of every school that was not ready for it. Same equation, two lessons. And only one conclusion that satisfies both: impact and readiness are the same number, so the people who own each half are working on the same outcome whether they admit it or not.
EdTech is not a purchase. It is a partnership
This is the bridge, and it is the thing the spreadsheet hides. A school is not buying a finished object that either works or does not, and a startup is not selling one. You are starting a relationship. A tool is a partner a school brings into its building, and like any partner it succeeds or fails on how well the two sides understand each other and keep talking.
That reframing matters because readiness is not something the school produces alone, and it is not something the vendor can promise from the outside. It is built in the overlap, and each of the four dimensions has a job on both sides.
On the technical side, the school's job is to be honest about the building as it really runs, the Tuesday reality of devices, bandwidth, and existing systems, and to put that in front of the vendor before anything is signed. The builder's job is to design for that reality rather than the brochure version of it. The failure mode is silence: a school that oversells its setup, or a vendor that never asks.
On the economic side, the school's job is to ask for the whole cost across the whole life of the tool. The builder's job is to show it plainly, including the parts that are inconvenient to mention. A partner who hides the total cost of ownership until the contract is signed is telling you something about the years ahead.
On the human side, the school's job is to protect the training time and name the people who will own this in the building. The builder's job is to design something a busy teacher can use without heroics, and to stay close through onboarding rather than vanishing after launch day. Adoption is a shared project, not a handover.
On the system side, the school's job is to align the tool to its curriculum and governance so it is not a stray novelty. The builder's job is to map to what is actually taught and to fit into existing structures instead of demanding everything bend around the product. A tool that cannot connect to the rest of the school stays an island no matter how good it is.
None of this works without communication, and most of it happens before any money changes hands. The best rollouts I have seen were not the ones with the most advanced tool. They were the ones where the school and the vendor were honest with each other early, and treated the first year as something they were building together.
If you are buying: how to make it work
Three habits turn all of this into a better decision.
Ask the four questions before you buy. Pause at the impact evidence and turn the four dimensions on your own building. Can it actually run here, on the devices and network you have on an ordinary day. Can you afford the whole of it, maintenance and connectivity and staff time included, not just the sticker. Can your people really use it, with the hours they genuinely have. And will the institution stand behind it, with a named owner who keeps it alive after the launch buzz fades. The goal is not to find a reason to say no. It is to see the gaps clearly enough to close them on purpose, instead of discovering them once the money is gone.
Read the tool, not just the pitch. A well-built product asks for less readiness in the first place, and the design choices give it away. Does it work offline, or assume a connection you cannot promise. Does it speak your students' languages, in audio as well as text. Does it integrate with what you run, or expect you to rebuild around it. Is there a real support structure, or a launch and a wave goodbye. The paper's own example is instructive: the authors run a free story-making app, Our Story, through the rubric. It scores excellent on cost, because someone chose to make it free, and weak on technical and system support, because someone shipped irregular updates and stood up no help behind it. The right call there is not buy or avoid. It is that a tool like that fits beautifully as a supplementary classroom resource and poorly as a core, school-wide system. Same product, two verdicts, decided by how you intend to use it.
Make the demo earn its keep. A demo is where most of these gaps are easiest to hide and easiest to expose. Ask them to show it on the kind of device your people actually use, not the demo iPad. Ask to see the teacher and admin view, not just the polished student screen. Ask what the first year of support really looks like, who answers when something breaks, and how often it has broken for schools like yours. Ask what the full cost looks like in year two. The questions a vendor welcomes, and the ones they deflect, tell you most of what you need to know about the partner you are about to take on.
If you are building: how to earn it
If readiness is something a school and a vendor build together, then a serious EdTech company should be doing real work to raise a school's viability, not waiting for the school to climb up to meet its product. From where I now sit, that comes down to a few commitments most feature lists never mention.
The first is to build for the Tuesday, not the brochure. The most useful thing a builder can do for a school's readiness is to need less of it: to hold up when the connection drops, on the devices students actually carry, in the languages they actually speak. Robustness is not a feature we bolt on at the end. It is a choice we make at the start, and it is ours to make, not the school's.
The second is to be honest about the whole cost, early. A school should never have to reverse-engineer the total cost of ownership from a year of invoices. A builder who respects the relationship puts the full picture on the table before the contract is signed, including the renewals, the maintenance, the connectivity, and the staff time that make the deal look less tidy.
The third is to treat onboarding and support as the product, not the afterthought. The features are the easy part. Whether teachers ever reach fluency depends on what we do in the first weeks and months, and on whether anyone actually answers when something breaks. The best thing we can build is rarely another dashboard. It is a path to competence that fits a teacher's real week, and a support line that is still staffed after the launch glow fades.
The fourth is to integrate, and then give the data back. A tool that asks a school to rebuild its world around it is raising costs and calling it innovation. The better path is to map to what is already taught, connect to what is already run, and make adoption visible, so both sides can see where it is sticking and where it is not, and fix it before a whole term slips away. That kind of traceability is not surveillance. It is the feedback loop readiness depends on.
None of this shows up on a feature comparison, and that is rather the point. The startups worth backing, and worth buying from, are the ones doing real work on a school's viability alongside their own product, because they understand what the research is quietly saying: their impact and the school's readiness are the same number, and they only get to claim the result if they help the school earn it.
The bottom line: it is a mindset, not a metric
There is an old habit, on both sides, of treating technology like medicine, as if it either cures the patient or poisons them. Technology does not really behave that way. It behaves more like an amplifier. Bring it into a ready school and it amplifies the strengths. Bring it into a fractured one and it amplifies the cracks, and then sends along the invoice.
So the most useful change is not a new checklist for buyers or a new roadmap for builders. It is a way of seeing that both sides can share. Stop treating tools as standalone objects that arrive, get judged, and either work or do not. A school is a whole, living environment that a new tool either fits into or strains against. A startup is not a vendor at the end of a transaction but a partner at the start of one. The question worth carrying into the next decision, on either side of the table, is not whether the tool is good. It is whether the tool is good here, with these people and these constraints, and whether the two sides will do the work to make it so.
What almost no one has, on either side, is a clear view of that readiness before the money is spent. That is the gap we built Novana to close. We help schools clean up and prepare the ground first, so the cracks in technical, economic, human, and system readiness get fixed before a tool is ever introduced, not discovered a term later. The point is to bring clarity up front, before implementation rather than after it, and to make readiness traceable, something both sides can see, score, and follow over time instead of a hunch carried into a procurement meeting. Get the ground right, and the tool finally has a chance to do what its evidence promised.
Based on Ammar A. Merhbi's essay "Why EdTech Fails (And the Hidden Metric that Predicts It)" and the research paper "Evaluating EdTech viability: a consolidated benchmark for implementation" by Kucirkova, Kardiakou, Schewe, and Pitchford, Smart Learning Environments (2026).