AI made code cheap. It didn't make customers, working infrastructure, or time cheap.
Anyone can build anything now. I know because I do it. Earlier this year I built LeadQuest, a production SaaS product, by myself with Claude Code. No engineers.
So people expect me to say building always wins. I don't think it does. AI made code cheap, and that moved the hard part somewhere else: customers who already pay, infrastructure that already works, and time. When you can buy those for less than it would cost to earn them, buy them.
I made this call the way I'd make any product decision, by working through why it mattered, what problem we were solving, which options we had, and what could go wrong.
Why it mattered
I'm the lead product manager at a company that runs a portfolio of sales and lead-gen tools. The strategy was simple: be the place a small team goes to run outbound, start to finish.
We were two-thirds of the way there. LazyLeadz found leads. Airfive handled customer support. Nothing in between sent the emails.
The problem
Our customers are founders, small sales teams, and agencies running their own outbound, with no sales-ops person to stitch tools together. Their workflow broke in the middle. They'd find leads with us, then leave to send cold email somewhere else. It happened on every campaign they ran, and every time they left, a competitor got a shot at becoming their whole stack.
I asked our community whether they wanted a sending tool inside our suite. They did, and we had the marketing partners to sell one the day it existed. The demand and the distribution were already there. The product wasn't.
The options
I looked at three ways to close the gap.
| Option | Effort | Impact | Time to revenue |
|---|
| Build it in-house | High. Our engineers were committed to the products we already had. | High, eventually | Months |
| Integrate a third-party sender | Low | Low. Customers still leave, and we don't own the revenue. | Weeks |
| Buy a working product | Low to medium | High | Weeks |
AI changes the first row less than people think. It gets you to a v1 faster. It doesn't get you deliverability, inbox warmup, sender reputation, or 100 paying customers, and in cold email those decide whether the product works at all.
The deal
Mailead was listed on a startup marketplace. Two founders had built it during the cold-outreach boom, got to about 100 paying customers, turned a profit, and stalled around $1K MRR. The product worked. They couldn't get it in front of more people, and that was the one thing we were best at.
I paid $10K up front. Then I kept both founders on for three months to integrate Mailead into our suite.
That meant the two engineers who knew the codebase better than anyone were still there at the exact moment I needed them. The deal got me a working product, its customers, and a three-month handoff from the people who built it.
What could go wrong?
- It was built in Bubble. Most buyers would read no-code as a red flag. For us it was a green one: our whole portfolio runs on Bubble and our developers work in it every day. No rewrite, cheap integration.
- It wasn't built to scale. The architecture topped out at a few thousand users, and the email stack would get expensive as we grew. I mapped where engineering had to go first and put it on the roadmap before we signed.
- The knowledge walks out the door. Founders usually leave after an acquisition and take the context with them. Keeping them on for three months solved that.
- Surprises diligence can't catch. There were a few. We fixed them on a product customers were already paying for, which is a much better problem than building one and hoping they will.
What happened
I launched Mailead to our community and brought in $45,000 in the first week. Over the next 12 months it did about $650,000 in revenue.
When I'd buy instead of build
I'd buy when:
- You have the distribution and the target doesn't. Their weakness should be your strength.
- The product works and people pay for it, so demand isn't a guess.
- It fits your stack, and your team can run it from day one.
- Time is your real constraint, not money or ideas.
I'd build when the product itself is the bet: nothing out there does what you need, or figuring out what to build is the goal. That's what LeadQuest was, and that's why I built it.
Mailead was a different kind of bet. The product already existed, and I had the customers it was missing. I'd buy it again tomorrow.
What this means for you
If you have an audience and a gap in your product, look at what's for sale before you open Claude Code. The micro-SaaS products that stall usually stall because their founders couldn't find customers. If distribution is the thing you already have, those stalled products are your cheapest path to a new line of revenue.
Work with me
I help founders decide which product bets are worth making, de-risk them fast, and turn them into revenue. If you're weighing a build-vs-buy call or looking at a micro-SaaS to acquire, send me a message on LinkedIn or find me on X at @Kenbuildsthings.