
Congratulations. Your Product Has AI. Now Tell Me Why I Should Care.
Six buyers sit around the table at a bank and none of them woke up wanting to buy AI. How to talk about your technology in terms of what it changes.
AI has changed the build vs. buy conversation, and now even mid-sized institutions can prototype. The harder question is whether you want to own everything that comes after.
A founder asks me whether to build something or buy it, and half the time the conversation is about features and what the license costs.
That's the wrong end of the problem.
The question I'd start with is whether this thing is the reason a customer picks you over the other guy. Not whether you can build it. You probably can. AI has made prototyping cheap enough that a decent team can stand up a working version of almost anything in a few weeks, which is why I think more people are getting this call wrong now than were five years ago.
Building it was never the expensive part. Owning it is.
What owning it costs when your buyer is a bank
I've sold into banks and credit unions for over twenty years. A deal runs seven to nine months. Somewhere in the middle you get handed to vendor management, and then you're into SOC 2 Type II, a security review, and a long conversation about how you touch the core.
Every component you built yourself is a component you answer for in that review. You own its patches, and you own it when the person who wrote it leaves. It's still yours at 11pm on a Sunday when an examiner is on site Monday morning.
Bought software comes with a company whose entire existence depends on getting that part right. That's worth more than the license fee makes it look.
When I'd build
Build when the capability is the thing your customer is actually paying for, and when you can honestly do it better than what's on the market.
I'll give you one I'd still defend. At Apiture I built the Salesforce instance from scratch and founded the BDR engine. That was a build, and I'd make the same call again, because the way we qualified and routed a bank opportunity was specific enough that a generic setup would have fought us for years.
When I'd buy
Buy when it's table stakes and speed matters more to you than a perfect fit. Buy when the vendor's whole company is built around this one problem and yours is not.
The honest test is what your best engineers spent last week on. If they were maintaining an internal dashboard while your competitor's engineers were shipping the thing customers pay for, you already have your answer, you just don't like it.
The question I actually ask
Five years from now, will a customer care that you built this yourself?
If the answer is no, buy it and move on. Nobody has ever renewed because of your internal tooling.
Where your attention goes is the whole decision, and attention is the scarcest thing at $5M to $20M in ARR. You get a limited number of hard problems per year. Spend them on the ones that show up in the sales cycle.
Anyway, that's roughly how I think about it. If you're in the middle of one of these calls right now and want a second read on it, I'm around.

Fractional CRO & Chief Growth Officer · GTM Advisor
Mark Solano is a revenue operator with 20+ years building and fixing sales systems for fintech and B2B SaaS companies. He has led sales organizations from seed to scale, rebuilt broken pipelines, and helped companies achieve predictable, repeatable revenue growth.
Connect on LinkedIn
Six buyers sit around the table at a bank and none of them woke up wanting to buy AI. How to talk about your technology in terms of what it changes.

The startup sales motion that got you to your first 40 customers breaks the moment you sell into a bank. Here's what actually closes financial institutions.
If this article resonated, let's talk about what's actually happening in your revenue engine.