Build, buy, or outsource. The decision that shapes your next two years in edtech.

Two founders asked me the same question in the same month. 

Both run learning platforms. Both had reached the point where the platform underneath them was starting to creak. Both wanted to know the same thing. Do we build the next version ourselves, buy something off the shelf, or hand it to a partner? 

I gave them opposite answers. 

That is the honest place to start this piece. There is no universally right answer here, and anyone who gives you one is really describing their own business model. Mine included. I do business development at an engineering firm. Outsourced product engineering is the thing I sell. Read everything below knowing that, and it will be more useful to you, not less. 

What this question is actually about 

Founders usually frame this as a cost question. It rarely is. 

Cost is the part you can put in a spreadsheet, and the spreadsheet always looks decisive. What the spreadsheet cannot show is where your scarce engineering attention will live for the next eighteen months. That is the real decision. Every platform path claims a share of your best people, your roadmap, and your patience, and each path claims a very different share. 

So the unglamorous question underneath all three options is this. What is core to your product, and what is just context around it? 

The features your learners would leave you over are core. Everything else, the auth, the admin panels, the video delivery, the reporting plumbing, is context. It has to work. It does not have to be yours. 

Get that line wrong and every option on this list becomes expensive. 

When buying off the shelf is the right call 

Early. Before you have proof that people will pay for what you teach. 

At that stage a ready platform is not a compromise. It is the cheapest tuition in this industry. The monthly fee that feels annoying is buying you the one thing you cannot build, which is evidence. Evidence that the course sells. Evidence that learners come back. Evidence about what they actually do inside the product, which is never what you expected. 

I have watched founders spend a year building a beautiful custom platform for a course nobody had bought yet. The platform was excellent. The lesson was brutal. 

You will know you have hit the ceiling of a bought platform when your roadmap starts turning into a list of workarounds. When the data model has no place to hold the thing that makes you different. I wrote recently about content tagging and mastery data, the plumbing an AI tutor needs before it can know your learners. Most off the shelf platforms give you nowhere to put any of that. The day you feel that wall is the day this question comes back. 
 

When building it yourself is the right call 

You have proven demand. You have compliance needs or domain workflows that no vendor supports properly. And, this is the part that matters most, you already have an engineering team whose single best use is this platform. 

That last clause is where I see founders overestimate themselves. Having engineers is not the same as having engineers to spare. The real cost of building in house is never the salaries. It is the opportunity cost. Every month your strongest people spend rebuilding an LMS core is a month they are not spending on the thing only your company can build. 

Coming from a background closer to the code than the contract, I will say this plainly. Engineers love building platforms. It is satisfying work with visible progress. That satisfaction is exactly why the opportunity cost stays invisible until a competitor ships the feature your users were waiting for. 

If the platform itself is your moat, build. If the platform is the floor your moat stands on, think harder. 
 

When outsourcing is the right call, and when it is not 

This is what I sell, so I will start with when it is wrong. 

If you cannot write down what you want, do not outsource it. Outsourcing turns ambiguity into invoices. A partner can sharpen a rough spec with you, but they cannot replace the founder who knows what the product must become. And if nobody on your side has the time and authority to make decisions weekly, do not outsource either. Unowned projects drift, and drift compounds quietly until the demo day nobody enjoys. 

Now the case for it. You have clear enough direction, no team to spare or no team at all, and speed matters because your market is moving. That combination is where a partner earns their keep. 

One thing has genuinely changed here, and it changes the maths. The old model was project outsourcing. Throw a spec over the wall, wait, receive software, discover what got lost in translation. What I see working now, especially in edtech, is the embedded model. A small dedicated pod that joins your standups, works in your repository, argues in your Slack, and stays. The knowledge compounds on your side instead of walking out when the contract ends. At Cubet we run this as an extended engineering room rather than a vendor relationship, and the difference shows up about three months in, when the pod starts catching problems you did not brief them on. 

The wrong question to ask a partner is what does it cost per month. The right question is what will my own team be free to build while you handle this. 

The filter that outlasts all three options 

Whichever path you take, run it through one filter before you sign anything. 

Does this leave my foundation ready for what is coming? 

I keep seeing the same story. A platform decision gets made purely on this year's cost, and it quietly closes next year's doors. Then the AI tutor conversation starts, and we open the hood, and the content is untagged, the user model cannot carry mastery, and there is no clean API for a tutor to read from. The cheap option became the expensive one. It just took a year to send the bill. 

Tagged content. A user model that holds progress. Interfaces something intelligent can plug into later. If the option in front of you cannot hold those, it is affordable now and costly forever. 

Back to the two founders 

The first was pre revenue with a small team and a big vision. I told him to stay on his off the shelf platform another year and spend his money proving the course sells. That advice cost me a deal. It was still the right advice, and he will remember who gave it to him. 

The second had real revenue, a clear spec, learners hitting the walls of a rented platform, and one overworked developer. We are building with him now. 

Same question. Opposite answers. The difference was never the technology. It was what stage of proof each business had reached, and where their attention needed to live next. 

So if you are sitting with this decision, the sharper question is not which option is cheapest. It is this. Which option lets your team spend the next year building the thing only you can build? 

If you want a second pair of eyes on your version of this decision, I am happy to compare notes. Twenty minutes, no deck, no pitch. Bring your current stack and your roadmap, and I will tell you honestly which of the three answers I would give you, including the two I do not sell.