We spent six months building our own Intercom. Hands up, who's done that
About one such story — and about how I now talk to clients when they start explaining why in their case 'writing beats buying'.
In 2022 I had a client — a product team, about fifteen people, building SaaS for HR. Normal business, normal revenue, normal team. And they had a project: write their own support chat.
I found out about it in the second week on the engagement. The CTO proudly showed me a Kanban board with, among other things, an epic. The epic was called "Customer Chat Platform." It had twenty-three tickets, four closed, nineteen in progress in various states of begun.
— So, — I said. — Why?
— Well, — said the CTO. — We don't want to depend on Intercom. It's expensive, it has customisation limits, vendor lock-in.
— How long will this take?
— Couple of months. Then iterate.
The project ran seven months. In that time roughly 60% of the functionality of 2019-era Intercom got written. Because of underestimation (always) and other priorities (always), the project kept starting, stopping, starting again. At one point a bug was discovered where messages got lost — only in mobile Safari on iOS 15.3.4 and only when message length exceeded 400 characters. That bug took two weeks to fix.
Month seven — they bought Intercom. The CFO sat with the CTO, they did the maths: over development time the team had spent roughly $45,000 in salary cost (not including coffee). Intercom would have cost them about $7,000 a year. Over seven months — $4,100.
The difference — $41,000. That's two strong hires. Which they didn't make, "because we don't have the budget right now."
I'm not telling this to bash the CTO. The CTO was fine. He honestly wanted the best. He just fell into a classic trap — confusion between core and non-core.
Core is what your customer pays you for. What you're different at from competitors. For this client, core was HR analytics. Not chat. Chat was non-core.
Core is never SaaS. If you buy an "LMS platform" and build an online school on top of it, you're not the platform's user — you're its competitor. A year in, you hit its ceiling.
Non-core is always SaaS. If you write your own Stripe, your own Slack, your own Intercom — you're heading into debt. Because Stripe spends more on engineering in a year than your entire yearly budget. And they still find bugs you won't have time to find.
That's the one question you must answer before any "build vs buy" argument. If "core" — stop reading, build (or assemble from blocks). If "non-core" — read on, but with a bias toward SaaS.
Further, I apply another six questions, because not everything non-core is worth buying, and not all core is worth writing from scratch.
Question two — cost of a "user question hour."
SaaS works now. Minus the subscription. Build works in N weeks, minus the team's salary for N weeks.
Simple formula: if SaaS_annual < 2 × developer_annual, and functionality covers 80% — SaaS wins.
Question three — does the SaaS have the API you need.
Buy Shopify — fine. But if warehouse is on one system, POS on another SaaS, courier on custom — your job is to stitch it together via APIs. Check the API before buying. If the endpoint you need isn't there, you'll pay both for SaaS and for building a proxy between it and everything else. The worst of all worlds.
Question four — will the vendor outlive you.
A ten-person SaaS startup promising to solve it all — risky. If they die in two years, you lose data, logic, process.
Check: is the company older than 5 years? Series B+? Documentation of migration to a competitor? If not — it's a short-lived SaaS, and migration will hurt.
Question five — data.
In regulated sectors (fintech, medical, government) this is often the only decisive question. If SaaS isn't in the right jurisdiction — build. Done.
In unregulated — still think. If critical analytics live on a SaaS and there's no export, you're the vendor's hostage. Their 40% price hike isn't negotiable.
Question six — how custom is your process.
SaaS is good when your process fits 80% of what the product supports. The further from average, the more customisations, plugins, workarounds. At some point, you're spending more on SaaS customisation than a build would have cost.
Rule: three customisations — normal, five — red flag, ten — time to migrate.
Question seven — maybe don't choose.
2026 changes the rules. Build vs SaaS used to be "write from scratch or buy ready-made." Now there's a third option: assemble from low-level blocks.
— Backend API — Hono / FastAPI in 30 lines.
— DB — PostgreSQL at any provider.
— Auth — Clerk / Supabase in an hour.
— Queue — Temporal / Inngest.
— LLM — OpenAI / Anthropic API.
What three years ago would have been six months of dev now ships in three weeks. Your build no longer opposes SaaS — it's made of pieces of SaaS. 20% custom + 80% borrowed. Default now.
Back to that CTO. A year after the chat story we crossed paths at a conference. I asked what they were doing now. He said they'd moved all non-core work back to SaaS (Intercom, HubSpot, ClickUp) and focused the team on one thing — HR analytics. Revenue up 60% year-on-year.
"I," he said, "spent that year learning one lesson: engineering work isn't always writing code. Sometimes it's deciding not to write it."
There's no universal answer. There are seven questions that turn a philosophical argument into a decision with reasons in fifteen minutes.
Next time you hear "let's write it ourselves / let's buy it" — pull out this list. It'll save you weeks and tens of thousands.