L
Learnosity
Guest
By Nina van der Behr, VP of Product at Learnosity
Let me tell you about the time I became a goatherd. Bear with me because it’ll be a product analogy further on. It’s also 100% true.
After becoming a homeowner for the first time and moving from Sydney to live amid the mountains, I took on the task of transforming a patch of adjoining land into a garden sanctuary.
I loved the idea of spending more time outside and getting my hands dirty cultivating the space. It was badly overgrown so I cut it all back. As I worked, I uncovered some amazing stacked stone garden beds, which I used to plant and nurture some root vegetables, greens, and native Australian flowers.
It was all going exactly as I’d hoped. But trouble was already brewing. When summer arrived, fresh off the back of a wet spring, my sanctuary burst into life in ways I wasn’t expecting and, I was forced to admit, couldn’t control.
Hedges shot up, weeds took residence in the garden beds, and blackberry bushes and ivy returned with a vengeance in areas I’d spent ages clearing out. Cutting back weeds is a lot less fun than growing veggies and flowers. I couldn’t maintain it all on my own but I knew if I didn’t do something, all my work would be undone pretty quickly.
By a stroke of luck, I spotted a story in the local paper about a business that had rehoused goats from a petting zoo and was renting them out. So, in an effort to regain the upper hand, I welcomed a herd of goats into my life.
They were a plucky bunch, clearly eager to help. Within a week they had eaten away the overgrowth and helped me restore order.
Still with me?
Devs, engineers, and product teams well versed in sprint planning, roadmap goals, and the complexities of ongoing maintenance will guess where this is going.
So here’s another time I chose to do all the weeding myself. At work, I opted to self-build authentication in an admin product. It was a problem someone else had already solved, but I invested heavily in it anyway, and it ate into our roadmap. It took a whole team three months to get it right.
In the end, no one was particularly excited by the promise of being able to reset a login password.
Eventually I called in the goats, enlisting a specialist vendor that freed us up to get back to the work our customers actually came for.
The product my teams work on is aimed mainly at enterprise-level edtechs. We build modular components, delivered via APIs, that allow their teams to build products of their own. From where I sit, I see teams repeat the same mistake as mine, just with assessment building.
The decision to take on an internal build doesn’t happen quickly. It’s not like in-house dev teams enthusiastically put their hands up after senior leadership asks “who’d like to build an entirely brand-new product that’s totally non-core to what we do?”
I’ve seen teams start with a one-year estimate that looks good in theory. Every quarter, the build decision gets remade by default, even as the reality slowly dawns that the work is far more complex than anyone imagined. So they put more engineering resources into it instead of correcting their original direction, only to find they’re three years in and still trundling along the same path.
Teams like this are full of smart, gifted people. So why do they decide to build what’s already built?
The three reasons I see recurring most often are:
In edtech, an area like compliance can dictate your entire product roadmap and system architecture. Enterprise buyers want solid evidence of compliance and accessibility. But what makes compliance really difficult is that the standards themselves are always changing (along with user requirements) and keeping up with them is a whole commitment in itself. WCAG 2.2 standards, for instance, hit assessment hard.
Take drag and drop questions, a staple of assessment. They let learners match terms, label diagrams, and order steps in a process. But to meet WCAG standards, every drag and drop question needs to offer learners three ways to interact: by dragging, clicking, and by keyboard navigation. The workload on dev and design teams ramps up when you apply that requirement across every drag-based question type you offer.
You might think you can just use modern design libraries to get you over the line, but even if you get the dragging, you won’t get all three ways of interacting, along with consistent scoring. This is the kind of thing that turns a two-week job into a six-month saga.
Success for teams dogged enough to stick with a non-core build often ends up creating a fresh share of stress. That’s because success brings load, and load eats roadmap because now you have to make it all reliable.
There is no room for error during critical exam periods when whole districts sit the same test. Every submitted answer needs to be able to survive a patchy Wi-Fi signal. Regular formative tests need to work across multiple device and browser types. Anything less than watertight performance thwarts learner engagement at a key moment. From what I’ve seen, this is where in-house builds end up paying most heavily. Resources that could have gone into new features and improvements on the core product get rerouted to maintain the non-core one. And as user numbers climb higher, so do the stakes.
But AI totally changes the conversation, right? In my view, not really. Teams can now ship a lot of code very quickly, but that just brings us back to maintenance and quality control. Who reviews what goes in? Who’s untangling the code that shouldn’t be there? Who’s wiring the product to hold up under load? If you want to prevent filling your codebase with AI-generated code that looks right but misses the edge cases your non-core build was meant to cover, you’ll still need a robust QA process. That requires skilled engineers. The question is whether it’s your engineers spending their time doing that, or someone else’s.
My prediction is that in five years or so we’ll view this moment differently. The real cost of AI will be a lot clearer, and it’ll make us product folk more deliberate about how we use it. People will better understand that shipping code quickly doesn’t translate into maintaining a live production system.
Good engineers can tell the difference between “could we build it?” and “should we build it?” Sometimes requirements might be so bespoke that nothing off the shelf fits the bill. Other times, a build might be so peripheral to your main offering that a lightweight in-house version will do. It really comes down to the level of complexity you’re comfortable owning.
Two questions for your engineers should make the decision clearer:
The simplest solution most of the time is to build your differentiation layer on top of a solid, proven base. As I learned, in quite literal terms, you can still tend your garden without the grind of weeding. Just let the goats handle the overgrowth.
Let me tell you about the time I became a goatherd. Bear with me because it’ll be a product analogy further on. It’s also 100% true.
After becoming a homeowner for the first time and moving from Sydney to live amid the mountains, I took on the task of transforming a patch of adjoining land into a garden sanctuary.
I loved the idea of spending more time outside and getting my hands dirty cultivating the space. It was badly overgrown so I cut it all back. As I worked, I uncovered some amazing stacked stone garden beds, which I used to plant and nurture some root vegetables, greens, and native Australian flowers.
It was all going exactly as I’d hoped. But trouble was already brewing. When summer arrived, fresh off the back of a wet spring, my sanctuary burst into life in ways I wasn’t expecting and, I was forced to admit, couldn’t control.
Hedges shot up, weeds took residence in the garden beds, and blackberry bushes and ivy returned with a vengeance in areas I’d spent ages clearing out. Cutting back weeds is a lot less fun than growing veggies and flowers. I couldn’t maintain it all on my own but I knew if I didn’t do something, all my work would be undone pretty quickly.
By a stroke of luck, I spotted a story in the local paper about a business that had rehoused goats from a petting zoo and was renting them out. So, in an effort to regain the upper hand, I welcomed a herd of goats into my life.
They were a plucky bunch, clearly eager to help. Within a week they had eaten away the overgrowth and helped me restore order.
When weeding woes creep into product development
Still with me?
Devs, engineers, and product teams well versed in sprint planning, roadmap goals, and the complexities of ongoing maintenance will guess where this is going.
So here’s another time I chose to do all the weeding myself. At work, I opted to self-build authentication in an admin product. It was a problem someone else had already solved, but I invested heavily in it anyway, and it ate into our roadmap. It took a whole team three months to get it right.
In the end, no one was particularly excited by the promise of being able to reset a login password.
Eventually I called in the goats, enlisting a specialist vendor that freed us up to get back to the work our customers actually came for.
Will build or buy ever die?
The product my teams work on is aimed mainly at enterprise-level edtechs. We build modular components, delivered via APIs, that allow their teams to build products of their own. From where I sit, I see teams repeat the same mistake as mine, just with assessment building.
The decision to take on an internal build doesn’t happen quickly. It’s not like in-house dev teams enthusiastically put their hands up after senior leadership asks “who’d like to build an entirely brand-new product that’s totally non-core to what we do?”
I’ve seen teams start with a one-year estimate that looks good in theory. Every quarter, the build decision gets remade by default, even as the reality slowly dawns that the work is far more complex than anyone imagined. So they put more engineering resources into it instead of correcting their original direction, only to find they’re three years in and still trundling along the same path.
Why teams build
Teams like this are full of smart, gifted people. So why do they decide to build what’s already built?
The three reasons I see recurring most often are:
- They have particular needs and want the flexibility and control to customize their product in ways they can’t initially predict.
This is a version of_Harvard Professor Mihir Desai’s thesis of the optionality trap, where “individuals just become habitual acquirers of safety nets,” essentially hedging their bets to the point of paralysis. In our context, every customizable system will need someone to maintain and extend it. Unexercised optionality just becomes additional technical debt. - Engineers have a natural ambition to rise to a challenge.
Most of them just love building. But complexity that’s interesting to an engineer isn’t necessarily valuable to their company, so why sink intellectual power into solving a problem that’s already been solved? - They feel integration might be too much work.
Styling and versioning considerations can make the integration lift seem as heavy as building it themselves, plus there’s a real concern that outsourcing makes them dependent on someone else’s roadmap. These are legitimate points. Integration isn’t free, but its costs are at least visible from the start. Build costs aren’t, and builds come with versioning and styling anyway, which is why one-year projections slide into three-year projects (these are things we actively work for customers already).
The overgrowth that won’t stop regrowing
Making things accessible
In edtech, an area like compliance can dictate your entire product roadmap and system architecture. Enterprise buyers want solid evidence of compliance and accessibility. But what makes compliance really difficult is that the standards themselves are always changing (along with user requirements) and keeping up with them is a whole commitment in itself. WCAG 2.2 standards, for instance, hit assessment hard.
Take drag and drop questions, a staple of assessment. They let learners match terms, label diagrams, and order steps in a process. But to meet WCAG standards, every drag and drop question needs to offer learners three ways to interact: by dragging, clicking, and by keyboard navigation. The workload on dev and design teams ramps up when you apply that requirement across every drag-based question type you offer.
You might think you can just use modern design libraries to get you over the line, but even if you get the dragging, you won’t get all three ways of interacting, along with consistent scoring. This is the kind of thing that turns a two-week job into a six-month saga.
Making it all work at scale
Success for teams dogged enough to stick with a non-core build often ends up creating a fresh share of stress. That’s because success brings load, and load eats roadmap because now you have to make it all reliable.
There is no room for error during critical exam periods when whole districts sit the same test. Every submitted answer needs to be able to survive a patchy Wi-Fi signal. Regular formative tests need to work across multiple device and browser types. Anything less than watertight performance thwarts learner engagement at a key moment. From what I’ve seen, this is where in-house builds end up paying most heavily. Resources that could have gone into new features and improvements on the core product get rerouted to maintain the non-core one. And as user numbers climb higher, so do the stakes.
AI has (obviously) entered the chat
But AI totally changes the conversation, right? In my view, not really. Teams can now ship a lot of code very quickly, but that just brings us back to maintenance and quality control. Who reviews what goes in? Who’s untangling the code that shouldn’t be there? Who’s wiring the product to hold up under load? If you want to prevent filling your codebase with AI-generated code that looks right but misses the edge cases your non-core build was meant to cover, you’ll still need a robust QA process. That requires skilled engineers. The question is whether it’s your engineers spending their time doing that, or someone else’s.
My prediction is that in five years or so we’ll view this moment differently. The real cost of AI will be a lot clearer, and it’ll make us product folk more deliberate about how we use it. People will better understand that shipping code quickly doesn’t translate into maintaining a live production system.
When to build and when to work with goats
Good engineers can tell the difference between “could we build it?” and “should we build it?” Sometimes requirements might be so bespoke that nothing off the shelf fits the bill. Other times, a build might be so peripheral to your main offering that a lightweight in-house version will do. It really comes down to the level of complexity you’re comfortable owning.
Two questions for your engineers should make the decision clearer:
- what would it take, realistically, to build this ourselves?
- what would it take to maintain at scale?
The simplest solution most of the time is to build your differentiation layer on top of a solid, proven base. As I learned, in quite literal terms, you can still tend your garden without the grind of weeding. Just let the goats handle the overgrowth.