Lumina LogoLumina
← All writing

When a B2B SaaS should not build its own AI feature

July 12, 2026/4 min read

The trap of "everyone's doing it"

It's predictable. You ship your product, find product-market fit, and then a founder or product person says, "We need AI." Maybe it'll differentiate you. Maybe it's theater. Maybe you've just seen three competitors announce something vaguely AI-shaped and you don't want to be left behind.

The part that doesn't get enough airtime: you probably shouldn't build it. Not yet. Not in-house.

I've been the engineer sitting in that room. I've also been the consultant hired to scope or fix the feature afterward. In both roles, I've watched good teams pour six months and a junior engineer into something that should've been either "we wait" or "we pay someone." This is what I've learned to look for.

Signal one: the ROI disappears when you ask for it

If you can't say what metric gets better by shipping this, don't ship it.

"Customers will love it" is not a metric. "We cut support tickets by 20%" is. Two kinds of ROI matter: revenue (does this unlock new GTM angles, higher pricing, bigger customers?) and cost savings (does it cut headcount, kill manual work, shrink infrastructure spend?).

The honest version: I can build you a document classifier for your support inbox. When it works, your team spends less time on routine questions and can focus on the hard ones. Or: this feature opens a customer segment we can't currently serve. Or: we lose half our next ten deals without it. Those are real.

But a lot of times it's not quantified. It's a hunch. Competitive fear. A board meeting. When the ROI is fuzzy, you stop caring about delays, maintenance, mediocrity. You're already spending the money; you need the win to be real. It won't be. Let this one go.

Signal two: you can't measure your own product

If you don't track user behavior or measure the impact of your existing features, you're not ready to tell if AI is working.

This one looks like: analytics bolted on as an afterthought. No real data pipeline. You don't actually know if users hate the thing you think they hate, or if it's just sales making noise. Your own feature releases don't have before/after data.

Adding AI to a product you can't measure is like debugging a system with no logs. You ship it, customers use it in weird ways, and you have no idea if it helps or hurts. You make decisions from phone calls. You blame the AI when the problem is your blindness.

I worked on a support bot once for a company with zero visibility into user satisfaction. We shipped it. Users hated it. Weeks later, we still didn't know if the bot was bad or if we just couldn't tell. We should have built measurement first.

If that's you, the fix is boring but real: instrument your core product better. Watch your users. In a year or two, when you can actually measure impact, go build the AI thing. It'll be faster and smarter.

Signal three: your team hasn't done this before

If you've never shipped RAG, fine-tuning, or whatever your AI piece needs, you're shipping two things: the feature and your expertise.

This doesn't mean you can't do it. Teams learn. But be honest about the timeline. You're not hiring an engineer; you're hiring a specialist or asking a generalist to spend six months learning on the clock while other work waits. Your first version will be okay, not good, because you'll make mistakes an expert wouldn't.

That's fine if the upside is huge. If it's not, you're paying a lot to build something you might never need again.

I've seen this pattern: hire a contractor, ship the feature, contractor leaves, and the team owns something they can't maintain. A year later the model drifts. Costs climb. The team keeps it running not out of love but obligation. That's a long, sticky tax.

The path forward is clear: if it's a one-off and the payoff isn't huge, buy it. Use an API. Outsource to someone who's done it five times. Or wait. In two years the tools will be cheaper, better, and simpler. You might miss a first-mover edge on paper. You'll probably win on cash and sleep.

The honest check

Before you staff up, ask yourself three things:

Can I define what winning looks like? Not vaguely (happier customers)—operationally (support resolves 30% more issues without escalation; we track that weekly).

Can I measure whether my existing product works? Do I have analytics and feedback loops that tell me if my features are good? If not, adding AI is the wrong move right now.

Does my team have the expertise, or am I funding a crash course? Would I be hiring a specialist or asking a generalist to learn a domain on the job? If the latter, is the upside large enough to justify the slow ramp?

If you answer "no" to any of these, the decision is simple: don't build it now. Maybe later. Maybe never. Building in-house is sexier than writing a check or waiting. But sexiness doesn't pay for maintenance. The right call usually does.

If you're working through this right now, I'm happy to talk through the specifics. I offer a free 15-minute scoping call: book one here. No pitch, just a clear-eyed look at your situation and what the options are.

Have an AI feature you keep putting off?