👨‍🏫

Engineering in Ed-Tech

By Jacob Kochian | June 19, 2025| 5 min read

While at Cornell, I worked part-time at AI-Learners, a company that develops games for students with disabilities. My first new-grad role was at Longtail Education, an early-stage ed-tech startup. Taken together I have almost 5 years of experience of engineering for ed-tech products; here are some insights that I've gathered along the way.

1. Expect skepticism and overcome it

Teachers and administrators have seen scores of tools come and go. I can name a plethora from just my experience going to school: Achieve3000, STMath, StudyIsland, IXL, Kahoot, Quizlet, Google Classroom, Canvas, Blackboard, Edmodo— and again, that is just from when I was a student. The sheer volume of ed-tech solutions that have been put in front of school staff has, for lack of better phrasing, honed their BS detectors. You need to quickly show that your platform has a real use case in or out of the classroom.

There are some strategies that you can use to overcome this and establish some goodwill with any prospective users. At both AI-Learners and Longtail, we actively developed alongside certain school districts that graciously volunteered to be design partners. As an engineer, I would hop on demo calls with real teachers and students and watch an authentic user journey in real time (which is an experience that I don't think is common for tech teams in most B2B companies). We'd listen to their complaints, iterate, and when we hopped back on a call a week or two later, they were genuinely appreciative and much more open to the product.

Before you even get on a call with a school district, establishing a partnership with ed-tech influencers is another great way to establish goodwill with school districts. These are usually current or former educators who have branched out into making content geared at teachers with classroom tips, upcoming conferences, or most relevant: new products that might be useful. Collaborating with an ed-tech influencer to strengthen both your product and its image is yet another way to overcome this (rightfully) ingrained skepticism.

2. Accessibility is everything

I've heard accessibility come up in every ed-tech conversation I've had with a teacher. At AI-Learners, accessibility was a core facet of the product's niche, so it was something that was already top of mind for us. However, if your product is unusable to a number of students because it is inaccessible, it's harder for a teacher or administration to find budget for it.

To that end, it is important to set aside dedicated time and staffing to making sure that any new features follow WCAG guidelines (yes I know this is a DC Comics situation but we always said WCAG guidelines). If applicable, a sprint should be dedicated to making your product work with popular assistive technologies like screen-readers, Dynavox, etc.

Additionally, schools are not going to be handing out shiny new Mac M4's to students to use your product. Make sure that your product can run on almost any hardware. If it's on the web, almost any browser. If it's for mobile, test on Android and iOS. I'm sure all those animations look nice, but if it can't run on a Chromebook from 2011 you might be alienating a large chunk of your TAM.

3. Design needs to be pick-up-and-play

As mentioned above, teachers have enough software to need to worry about how to use. They also have to worry about school supplies, seven other trainings from admin, grading papers, and not to mention tracking down the pizza guy for the end of semester party. The point being: their plates are perpetually asymptotically approaching full.

Teachers have some time to learn your product, but it really needs to be intuitive. If there is some aspects of your design that are unclear to someone that's been left out of modern design trends, it's going to cause frustration and lead to lower adoption. Tech for tech's sake here is not going to cut it. Listen, I love a tooltip as much as the next guy, but if it has some load-bearing information don't assume that anyone is going to take the time to hover over what you need to to get it to show up, even if it's in bright red text that says HOVER OVER ME.

Again, collaborating with educators early to get feedback and iterate is a great way to mitigate the risk that your product is too complex.

4. The children are our future, and also the worst

At my current role at Merge, security is at the top of mind in everything we do. Key decisions are made daily that ensure that the biggest companies in the world can rest easy knowing that their customers' data is secure.

None of those decisions are as hard as designing an ed-tech product that is insulated from kids being kids. Some students are going to try and join sessions with vulgar pseudonyms. They may try and optimize their experience to play as many annoying sound effects as possible. We even had a case where a student got rate limited, god knows how, they were playing a quiz on Spanish marine wildlife.

If students are directly interfacing with the product, make sure that teachers have robust admin functionality built in to quickly mitigate some of these antics.

and more...

There are a host of other fun quirks that come with working at an ed-tech company: brutal seasonal sales cycles, current pushback against AI, trying to find just the right amount of gamification, and more. But ultimately, the work that you are doing has a much more tangible value, at least in my mind, than B2B SaaS products. It has enough intrinsic meaning that working through the above isn't really an issue.

Tagged:engineeringed-techstartup