The short version
- Feature comparisons always choose the vendor, which is why they are the wrong test to run.
- Price the exit at the same time as the entry. Leaving a hosted system is billed in records rather than in pages.
- Own the source files and the delivery layer stays swappable, which is what keeps the decision reversible later.
Buy when the workflow is standard, build when the workflow is your product. We built a customer learning centre for a client rather than buying a course platform, because the courses taught that product’s own admin workflow.
A course platform would have hosted those lessons. Keeping them true to the product through the next release is the part it could not do.
What is the actual build or buy test?
One question: is this workflow standard across companies, or specific to your product? Payroll is standard. So is email delivery, where building your own version buys deliverability problems you cannot staff.
The test fails the moment it turns into a feature comparison. Vendors win those by construction, because their product shipped years ago and yours has not started. What you are deciding is whether the thing you are automating looks like everybody else’s version of it.
The five questions that decide it, and which way each one points:
| Question | Points to buy | Points to build |
|---|---|---|
| Is the workflow standard across companies? | Yes, and vendors compete on it | No, it exists because of how your product works |
| Whose data does it hold? | Data that exports in a standard format | Data that only means something inside your app |
| Who sees the output? | Your own team | Your customers, on your domain |
| How often does it change? | Rarely, and the vendor ships the change | Every release, because it tracks your product |
| What happens when you leave? | You export and move on | You migrate records, not pages |
Why do teams build things they should buy?
Because they have engineers. We have three AI engineers, which biases this agency towards building, and that bias is worth saying out loud before anyone estimates anything.
The second reason is that buying feels like conceding the work was not special.
What does buying actually cost after the first year?
The subscription is the part everyone compares. The costs that arrive later are quieter. Content on a vendor subdomain sends its search value to the vendor. A per-learner meter grows with exactly the thing you were trying to grow.
Then there is the export, which hands back your records without the structure that made them useful. A migration on a different account of ours moved 42 routes, 387 entries and 545 assets out of a hosted CMS, and the routes were the cheap part of that job.
When is building the right call?
When the content is the product’s own workflow. The learning centre taught platform administrators how to run the client’s software. A course platform can host material like that, and it has no way of knowing when a release makes a lesson wrong.
It also cannot sit behind your publish gate. A hosted platform sits outside every check you have written. Adding one more content type to a site you already maintain is a smaller job than the vendor comparison implies.
Material that teaches your own product ages with every release, and whoever holds it inherits that maintenance for as long as the product ships.
How do you keep the decision reversible?
Own the source. If the courses live as files in your repository, moving them to a vendor later is an import. If they live in the vendor’s editor, moving them out is the migration that gets quoted in routes and billed in records.
What you are picking is the direction the switching cost points.
Both directions of this decision have a longer version: what leaving a hosted system costs and building software when you are not a software company.
Frequently asked questions
How do you decide whether to build or buy software?
Standard workflows have funded vendors competing on them and you will not out-build that. A workflow that exists only because of how your product works has no vendor, so buying means bending your process to someone else's model.
When is building an internal tool a mistake?
When you are recreating a category that already has established vendors and your only differentiator is a detail no customer sees. You inherit the maintenance permanently and lose on everything except that detail.
What costs are missing from most build versus buy comparisons?
The exit. Search value accrues to the vendor's subdomain, meters grow with your success, and the export returns records without the structure around them. A migration on a different account of ours moved 387 entries and 545 assets out of a hosted CMS, which is where the cost of leaving sits.
Should customer training live on a course platform or your own site?
On your own site when the training teaches your product's own workflow, because it has to track releases and belongs on the domain where the search value stays with you. A course platform is right when the material is generic or needs enrolment and certificates you would otherwise build.
Does having engineers change the build or buy decision?
It changes the cost, not the test. In-house engineering makes a build cheaper to start and no cheaper to maintain. Three of our team are AI engineers, which biases us towards building, so the test gets applied before anyone produces an estimate.
How do you keep a build or buy decision reversible?
Keep the source under your control. If the content lives as files in a repository you own, moving to a vendor later is an import job. If it lives in the vendor's editor, moving out is a migration billed in records.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
