Build, Buy, or Bury: A 20-Minute AI Feature Scorecard for 2026
Photo: product team whiteboard AI feature build buy decision scorecard, via media.giantfreakinrobot.com
Somewhere in your product there is an AI feature. Maybe it summarizes tickets. Maybe it drafts emails. Maybe it writes a 'smart' description that nobody asked for. The feature shipped, the demo worked, and now it sits in the roadmap like a tenant who pays rent in applause.
The question in 2026 is not whether you have AI. It is whether that feature creates margin, noise, or liability. Build, buy, or kill is the right frame, but most teams run it as a vibes check. This is a 20-minute scorecard you can run with the people who actually own the feature.
The AI Feature You Forgot You Shipped
AI features have a way of escaping their original scope. A support copilot starts as an internal tool, then gets exposed to customers, then gets a pricing tier, then gets a security review. By the time anyone asks whether it should exist, it has three dependencies and a Slack channel.
Start by naming the feature in one sentence a customer would understand. Not 'AI-assisted workflow augmentation.' Something like: 'It reads incoming support tickets and drafts a first reply.' If you cannot say it plainly, that is already a signal. Complexity is not the same as value.
Score the Feature, Not the Demo
Use five inputs, scored 1 to 5. Keep it rough. The goal is a decision, not a dissertation.
- Customer pull. Are people asking for it by name, or are they ignoring it? A feature with strong pull can survive a mediocre margin. A feature with no pull needs a very good reason to exist.
- Margin impact. What does it cost to run per active user, including model calls, retrieval, and human review? In 2026, model pricing is cheaper than it was, but agentic workflows and long context windows can still surprise you.
- Differentiation. Would a customer switch to you because of this? If the answer is no, you are paying for table stakes. That can be fine, but it should be a conscious choice.
- Liability. What happens when it is wrong? A bad summary is annoying. A bad answer to a compliance question is a lawsuit. Score the worst realistic failure, not the average one.
- Maintenance drag. Who owns prompts, evals, model migrations, and vendor changes? If the answer is 'the founding engineer, unofficially,' the feature is already more expensive than it looks.
Add the scores. A total of 20 or more means build or double down. 13 to 19 means buy, partner, or narrow the scope. Below 13 means kill or bury it behind an internal flag. The numbers are not sacred. The conversation is.
The 2026 Cost Inputs That Change the Math
Three cost shifts matter this year. First, small models are good enough for many classification and extraction tasks. If you are using a frontier model to sort support tickets into five categories, you are overpaying for a job that a smaller model can do. Second, retrieval costs are more predictable than they were, but bad retrieval is still the most expensive bug in the system because it produces confident wrong answers. Third, human review is not free. If your AI feature needs a human to check every output, you have built a faster queue, not a margin engine.
Buy is often the right answer for features that are necessary but not differentiating. Do not build a document parser because you can. Build the workflow around the parser if that is where your customer actually feels the pain. The same logic applies to evals and monitoring. Buy the plumbing, build the judgment.
A Real Teardown: The Support Copilot
Imagine a B2B SaaS company with a support copilot. It drafts replies to tickets. Usage is decent: 40% of tickets get a draft. But the team suspects it is not paying off.
Customer pull: 3. Agents use it, but customers do not ask for it. Margin impact: 2. Long tickets with attachments burn context, and the average draft costs more than the team assumed. Differentiation: 2. Competitors have something similar. Liability: 2. A wrong refund policy answer creates real risk. Maintenance drag: 2. One engineer spends a day a week on prompts and model changes.
Total: 11. Kill? Not necessarily. The teardown shows the feature is too broad. Narrow it to billing questions with a strict retrieval set and a human approval step. Re-score in 30 days. If margin and liability improve, keep it. If not, bury it. The point is not to be ruthless for sport. The point is to stop paying for a feature that is quietly taxing the roadmap.
The 20-Minute Decision Meeting
Put three people in a room: the product owner, the engineer closest to the feature, and someone from sales or support who hears customer pain. Set a timer. Read the one-sentence description. Score the five inputs out loud. Argue only where scores differ by two or more. Decide: build, buy, or bury. Assign one owner and one review date.
The meeting should produce a decision, not a task force. If the team cannot decide in 20 minutes, the feature is probably not important enough to keep the current scope. That is useful information too.
When Killing Is the Growth Move
Founders treat killing a feature as a loss. It is often the opposite. Every AI feature you keep alive consumes attention, budget, and trust. A feature that is wrong 8% of the time in a high-stakes workflow is not a feature. It is a liability with a launch announcement.
Bury the ones that do not score. Buy the ones that are necessary but not distinctive. Build only where the customer feels the difference and the economics hold. In 2026, that is not an AI strategy. It is just good product finance.
