Draft for Tamir's review. Not published.
Split the need into functions
List what the system must do on day one. Mark which functions your customers notice or your business competes on, and which are commodity, such as payments, booking or standard reporting. Packages already carry the commodity parts, including traceability and audit records.
Build where your own data and decisions give you an edge. Buy where a product already does the job and keeps up with rule changes. When the hard part is the data, such as linking records across systems, no tool does it for you. Fix the data first and choose the tool after.
Count the cost of owning it
A home-built system needs a team for its whole life, well past the first version. Ask who supports it when its authors leave. Price that over several years against the vendor's fees at your growth plan.
Full builds usually take longer than engineers estimate, because of edge cases nobody listed. Buying has its own costs: integration, fees that grow with use, and a product you may not be able to change. Check the vendor's terms on data ownership, export and exit before you compare prices.
Where the seats differ
If you're on the board and a regulatory date is close, weigh deadline risk first. Ask what each option can have in place and tested by the date, with evidence. Then ask who updates the system when the rules change. When management asks to fund internal development, ask what benefit purchase or partnership cannot give.
If you run the company, judge the in-house plan on named people and a first use case in production. Judge the vendor or agency on what it has shipped and still supports. If you're the CIO or CTO, a short design exercise helps: have each option show how it handles one real order from start to finish.
What to check before you decide
- List the functions needed on day one and mark which ones an off-the-shelf product already does.
- Ask the internal team for a maintenance plan over five years, including who supports it when the authors leave.
- Price both options over three years: vendor fees at your growth plan, and the team's full cost including the work it stops doing.
- Check the vendor's terms on data ownership, export and exit.
- Ask the vendor or agency for products it shipped and still maintains, and speak to those clients.
- Check what your auditors, regulator or key customers require, and whether a home-built system can meet it.
- Consider a middle option: buy the commodity parts and build the layer that makes you different.
Questions people ask
Build or buy a regulatory reporting system with a deadline approaching, what should the board weigh?
Weigh the deadline risk first: what can be in place and tested by the date under each option, with evidence rather than confidence. Then weigh rule changes: who updates the system when the regulator changes the report, and how fast. It depends on the team's record on delivery and on the vendor's record on regulatory updates.
When should a healthcare board fund internal AI development rather than licensing?
Fund internal development when the intended benefit and ownership rationale survive comparison with available alternatives. It depends on usable data rights, clinical validation capability, ongoing support, and the institution objectives.
My competitors have apps, should I build a custom app or use a white label one?
Start with white-label if speed matters and the terms give you the customer data and a way out; build custom when the app is how you compete and you can fund it for years. Judge the white-label vendor on exit and data, and the agency on what it has shipped and supported. It depends on whether your customers choose you for the app or for the service behind it.
Core system vendor offers built in AI and my CIO wants an in-house AI team, how do I decide?
Use the vendor's AI for standard functions where the vendor's data model already sits, and build in-house only where the bank's own data and decisions give it an edge, such as risk, pricing or customer insight. Judge the in-house plan on named people and a first use case. It depends on what the vendor's AI actually does with your data and on whether you can hire and keep the team.
Should our hospital build its own patient app or join an existing health app that already has users?
Join where the patients are for the functions patients expect everywhere, such as booking and results, and keep what makes your hospital different, such as care plans and follow-up, under your control. Judge the platform on data terms and on whether you can leave. It depends on how your patients find you and on what the platform does with their data.
Should we acquire an automation company or buy its operating capability?
Compare ownership with licensing or purchasing the required capability. It depends on strategic control, demonstrated maturity, retained talent, ongoing development obligations, and what ownership adds beyond a supply agreement.
Should we build our own MES on our data platform or buy a package for a food plant?
Build when your processes are unusual and you can commit a team to the system for its whole life, well past its first version. Buy when traceability, quality records and audits are the main need, because packages carry those out of the box. It depends on how many years you can fund maintenance of an in-house system.
Should a charging operator build its own back end and app or keep paying a white label vendor per session?
Build only the parts that make your network different, such as pricing, fleet features and partner integrations, and keep buying the commodity parts such as payments and roaming. A full build takes longer than engineers estimate because of edge cases in charger behavior. It depends on your session volume, your team's size and what the vendor contract lets you take with you.
Our biggest retail customer requires electronic data exchange within months, buy an integration service or build it?
Buy the connection to the retailer's format, because services exist that already speak it, and spend your own effort on making your ERP data correct enough to send. Most failures in these projects come from the data. The connection is rarely the cause. It depends on how clean your item, order and inventory data is and on how many more customers will ask for the same.
We must report emissions per vehicle and route and the data is in separate systems, build the data links or buy a reporting tool?
Link the data first, because the join between vehicle, route and fuel or energy is the hard part and no reporting tool does it for you. A small, owned dataset with that join serves reporting, planning and the next electrification tender. It depends on whether your telematics and depot systems share vehicle and trip identifiers.
How I can help with this decision
- Ask or talk (Free)
- I give my view on which of your needs favor building and which favor buying, and the one question to put to your team or vendor.
- Review (Pay if it was worth it)
- I write an independent build-or-buy assessment of your functions, team, data and vendor terms. I recommend what to build, what to buy and in what order.
- Retain (When it makes sense)
- I stay close through selection or the first release to review scope decisions against the plan you chose.