Decide the problem first, not the technology
The mistake starts with the question “build or buy.” I would first ask whether this function is a competitive advantage. For typical transcription you can buy. For unique data and rules — you may need your own workflow.
The mistake I would remove first: Building your own system for control over a commodity task.
What to prepare and what result to expect
- Outcome: You compare options by total cost of ownership and validate them on one pilot.
- Write down users, process, integrations, data, timeline, mandatory constraints, and an exit path from the solution.
- Keep source data and access rights separate from the output so you can verify what the build-or-buy decision work actually did.
- For two options measure time to result, accuracy, cost per operation, data export, and vendor replacement.
Compare buy, build, and hybrid on one pilot
- Gather requirements before choosing
In one table lock task, users, integrations, data classes, SLA, volume, and hard prohibitions.
Проверьте: Requirements do not include the word “modern” without a measurable meaning.
Если не сработало: Replace a wish with a criterion: time, accuracy, access, export.
- Score options with weights
Fill a 1–5 matrix: fit 25%, security 20%, speed 20%, 3-year cost 20%, control/portability 15%. Score = sum(rating × weight) / 5.
Проверьте: Weights reflect business risk, not a developer’s personal taste.
Если не сработало: Align weights with the process owner and security.
- Calculate TCO
Buy TCO = licenses + implementation + integrations + training + exit. Build TCO = analysis + development + testing + infrastructure + support.
Проверьте: There is an estimate for support and year-three ownership.
Если не сработало: Add a range and state assumptions explicitly.
- Run the same pilot
Give both options one input sample and one result criterion. Check not only quality, but how easy it is to fix an error and export data.
Проверьте: The decision is made after a real task, not a presentation.
Если не сработало: Stop the pilot if you cannot safely verify the result.
I compare three options
Add SaaS, API + your own workflow, and a fully custom system to the table. For each, calculate 3-year TCO: launch, licenses, API, integrations, people, security, infrastructure, support, and migration. Do not compare a monthly subscription with a developer’s salary.
Score launch speed 20%, fit 20%, TCO 20%, data control 15%, security 15%, and vendor exit 10%. Score = sum(rating × weight). Before deciding, run 20 real cases and try exporting the data.
TCO = launch + licenses + API + integrations + people + security + support
Score = sum(rating * weight)Vendor exit test
Request an export in a clear format, check data deletion, access rights, SLA, the price of 10× volume growth, and migration timeline. If the company cannot name a system owner after launch, it does not matter whether this is build or buy — the solution is not ready yet.
A pilot that settles the argument
Give SaaS, an API workflow, and custom development the same sample of 20 real examples. For each record time, accuracy, manual fixes, cost, and whether source data can be exported. Do not decide from a demo with perfect input.
If a ready-made service covers 80% of a typical process and the remaining 20% can stay manual, that is often better than a full platform. Choose a custom system only with an owner, support budget, and exit plan — otherwise “control” ends with one developer who went on vacation.
How to score an option that will live three years
| Criterion | Question | Good sign |
|---|---|---|
| Input | What exactly enters the build-or-buy decision? | Write down users, process, integrations, data, timeline, mandatory constraints, and an exit path from the solution. |
| Action | What is the system allowed to do on its own? | Only pre-listed actions, with no access to the whole account |
| Verification | How do you know the result can be accepted? | For two options measure time to result, accuracy, cost per operation, data export, and vendor replacement. |
| Failure | Where does an unclear case go? | Keep the option the team can support, even if it is less impressive in a demo. |
What should change after setup
You compare options by total cost of ownership and validate them on one pilot.
Why “we’ll build it ourselves” is almost always underestimated
Building your own system for control over a commodity task.
Buying a tool without API and data export.
Not counting support and internal team time.
Comparing demo features instead of a real operation.
When the choice already affects business architecture
Bring in a specialist when the choice touches architecture, multiple systems, personal data, or multi-year TCO.
What to check in the contract and in the code
When does hybrid fit?
When the base part can be bought and unique rules, data, or integrations stay with you.
Should you include the owner’s salary?
Yes. TCO includes hours of the team, contractors, and the internal owner.
When should you buy ready-made?
When the task is typical, speed and integrations matter, and requirements do not create a strong differentiator.
When should you build yourself?
When the process is unique, data cannot go outside, special logic is required, or license cost grows faster than development.
