The build vs buy decision with an auditable matrix
AI researches and builds the comparison matrix for a vendor or tool in minutes, but the price, feature, or limitation it cites can be outdated. The criteria that matter for your context, and the signature on the decision, stay yours.
You need to decide between building a processing queue system internally or hiring a managed service, and you have a week to present the recommendation. You ask AI to compare three options based on public documentation, and in a few minutes it returns an elegant matrix, with price, throughput limit, and setup time for each. One of the listed prices is for a plan the vendor discontinued four months ago, replaced by one 40% more expensive. If the decision had come straight from that matrix, the budget presented to the director would already be born broken.
Legal is evaluating switching contract management tools, and asks you to technically validate the comparison AI built between two vendors. It points out price per user and version history retention, and states one of the vendors keeps "unlimited version history", an important point for legal traceability of old drafts. The quoted plan, in fact, retains history for only 24 months, and older versions require a plan upgrade. Without checking this at the official source, legal would sign a contract that doesn't cover the retention period it itself internally requires.
You're deciding between two performance management systems to replace the company's manual spreadsheet, and the budget needs approval by Friday. AI builds the matrix comparing the two, with price per employee and calibration features, fast and organized. It describes one of the systems as including "native payroll integration", a point that would weigh heavily on the choice. The integration exists, but as a separately paid add-on, not included in the quoted plan. Checking this on the official pricing page before closing avoids a budget that's already incomplete at birth.
The product team is evaluating switching feature-flag tools because of segmentation limitations, and you ask AI to compare three market options. It builds the matrix with price, simultaneous flag limits, and custom attribute segmentation support, all fast. It states one of the options "supports unlimited segmentation" in the evaluated plan, when the current documentation shows a ceiling of 50 custom attributes on that same plan. If your use case goes past that ceiling, the wrong choice would only show up weeks later, in production, without this check beforehand.
The sales team wants to switch CRMs after complaining about proposal automation, and you build a matrix with AI comparing three platforms. It quickly summarizes price per user, automation limits, and e-signature integration. It describes one of the platforms as having e-signature "included in the standard plan", a detail that weighed on the team's pre-selection. In practice, that integration is a separately sold add-on, a cost that wasn't in the initial quote. Checking the current pricing page avoids closing a contract with a hidden cost surprise.
Operations is evaluating switching the delivery routing system, and you ask AI to build the matrix between two vendors, with price per processed order and carrier integration limits. It confidently points out that one of the vendors has "support for 40 partner carriers", a decisive number for your operation's coverage. The vendor's current list, on their own site, shows 24 carriers actually integrated, the rest is on "roadmap". Contracting thinking the coverage already existed would leave entire regions without tracking working in the first month.
Before an external audit, the compliance area is evaluating hiring a consent management tool to comply with LGPD, and asks for your technical help comparing options. AI builds the matrix comparing two tools, with price, audit capability, and data retention policy. It states one of them "generates a complete audit trail by default", a non-negotiable requirement for the risk committee. In the documentation, that complete trail is only generated with an additional module, sold separately. Reporting this to the committee as an included feature, without checking, would create a compliance gap discovered only at the real audit.
The design team is evaluating switching remote usability testing tools, and you help build the comparison with AI. It builds the matrix with price per recorded session and automated accessibility testing support, fast and organized. It states one of the tools offers a "complete WCAG accessibility report" in the standard plan. Opening the documentation, that complete report only exists in the higher-tier plan, the standard one brings a summarized version with half the criteria. Checking this before deciding avoids buying smaller accessibility coverage than promised.
The board needs to decide whether the company enters an adjacent market this year, and asks for a market-size summary by tomorrow. You ask AI to research and build a TAM, SAM, and SOM comparison with cited sources, and it returns a figure of $3.1 billion, attributed to a heavyweight industry report. The cited report exists, but discusses a different adjacent segment, not yours; AI approximated because it seemed reasonable. Bringing that number to the board without opening the original report would have backed a market-entry decision on a figure that isn't your real market's.
Whoa, anyone who's sat through a vendor meeting knows how this usually goes: the salesperson shows the pretty slide, promises the world, and six months later, implementing it, you find out that decisive feature was only in the enterprise plan. The build or buy decision has always been like this, made on a pitch, on guesswork, or on a shallow half-hour of research because nobody had time for more. AI solves the rush part, it researches fast. What it doesn't solve on its own is the part that always hurt: making sure what's in the matrix is true now, not the six-month-old version it read somewhere.
The core idea of this lesson. AI researches documentation, changelogs, and pricing pages for several options and builds, in minutes, a comparison matrix that used to take days. That's a real gain. The risk is that it cites a feature, price, or limitation with the same confident tone whether it's up to date or not, and a plan that changed or a limitation already fixed in a new version might be hiding in a pretty row of the matrix. That's why every decisive row needs a checkable source before becoming an argument. And the criteria that really matter for your context, lock-in, total cost of operating and not just the license, your team's real capacity to maintain, stay your judgment, not AI's.
01The classic build vs buy problem
Every growing company reaches this fork: build the solution internally or buy from a vendor. And historically this decision goes wrong in two opposite ways, and both are expensive. One way is deciding on the vendor's pitch, without real research, and finding out months later the product doesn't do what the slide promised. The other is deciding to build out of technical pride, without checking that a ready-made solution already solved 90% of the problem, and spending months of engineering reinventing something that already existed, mature, in the market.
The common denominator of both mistakes is the same: shallow research. Nobody had half an hour, let alone a whole day, to carefully read three different vendors' documentation. AI attacks exactly this time bottleneck. What it doesn't solve on its own is the second part of the problem, making sure what it read is still true. Fair?
02What AI does well: researching and building the matrix
Here's the real gain, and it's big. Ask AI to read the public documentation of each option you're considering, and build a side-by-side matrix with the criteria that matter: price, technical limits, integration, support, implementation time. What used to require a whole day opening tab after tab for each vendor, it delivers organized in minutes, with pros and cons for each row.
Notice the gain: you walk into the decision meeting already with a structured base, instead of opening the first vendor's first tab. But also notice the matrix is a research draft, not a closed truth. That's the next point.
03The danger: made-up feature or price with the look of certainty
Here's the same pattern you've seen in other lessons in this module, now dressed up as a comparison matrix. AI can cite a price the vendor already adjusted, a feature that only exists on a pricier plan, or a limitation already fixed in a new version, and it does so with the same confident tone as always. Public documentation changes, plans change, and AI's training has a cutoff date that doesn't always keep up with the vendor's latest update.
The antidote is simple and not optional: before any row in the matrix becomes a decision argument, it needs a source you can open right now. The vendor's current pricing page, the latest changelog, the technical documentation in force, or a direct question to the vendor's sales team in writing. If the row doesn't survive that check, it doesn't make it into the final version of the matrix that goes to the decision meeting.
Learn more: why "sounds reasonable" is the warning sign, not the sign of safety
When AI describes a feature with correct technical detail and a confident tone, your brain relaxes its guard, assuming it was verified. But textual fluency isn't evidence of truth, it's just the tool's default style, present in both the right answer and the wrong one. The most dangerous case isn't when AI errs blatantly, an obvious mistake draws attention on its own. It's when it errs plausibly: a price just slightly outdated, a limitation that sounds coherent with the rest of the product. Precisely because it looks reasonable, this kind of error goes unnoticed if nobody checks the source. The practical rule flips your instinct: the more decisive a claim seems for the choice, the more it deserves checking, not less.
04What's yours: the criteria that matter for your context
A perfectly audited matrix can still lead to the wrong decision, if the criteria used aren't the ones that really matter for your operation. And here AI can't decide for you, because it doesn't live inside your context.
Three criteria tend to matter more than they show up in a price-and-feature matrix. The first is lock-in: how expensive and slow it is to leave this tool or vendor after two years of use, if the relationship doesn't work out. The second is total cost of ownership, which includes not just the license, but your team's time to configure, maintain, and troubleshoot that solution, a cost that rarely shows up on the pricing page. The third is your team's real capacity: if the option is to build, does your team have, today, the skill and the time to keep that running a year from now, not just to launch the first version. Weighing these three is context reading, and context reading stays yours.
05The final ruler: propose, check, sign
Close the reasoning with the same ruler that runs through this entire module. AI proposes the matrix, fast and organized. The team checks every decisive row against a source that opens right now, not against AI's memory. And one person signs the final decision, with their name on it, able to defend why this option outweighs the others if someone questions it later.
"The matrix AI built said so" is never an acceptable defense when the decision goes wrong. Whoever signs the contract, or signs the decision to build, is who answers for the result. AI sped up the research; the responsibility for the choice never leaves your hands.
Do it now
Pick a real build vs buy decision on your desk right now, your real task or another one you know you'll need to make soon.
- Ask AI to build a comparison matrix of two or three options (including the build-internally option, if it makes sense), with explicit criteria: price, technical limit, integration, support, implementation time.
- Choose the three most decisive rows in that matrix, the ones that would weigh most on your final choice.
- Check each of those three rows against a source that opens right now: current pricing page, changelog, documentation in force, or a direct question to the vendor.
- Note whether any of them changed relative to what AI had cited, and adjust the matrix before moving the decision forward.
You've just turned a pretty matrix into a trustworthy one, and the difference between the two was exactly that check.
Practice
1. What's AI's correct role in the build vs buy decision?
2. AI described, in the matrix, that a security scanner 'automatically blocks the merge when it finds a critical vulnerability', but this feature only exists in the enterprise plan, pricier than budgeted. What should you do before deciding?
3. Besides checking price and features at the source, what else needs to enter the judgment before deciding build vs buy?
For the board
On the vendor meetingthe decisive feature usually turns up six months later, and only on the enterprise plan.
On the matrixevery decisive row needs a checkable source. Price and feature are confirmed against the exact plan.
On judgementa correct matrix still leads to the wrong decision if the criteria that matter to your business are left out.
Thanks for the feedback. It helps sharpen the next lesson.