--- title: "We spent seven months building our own Intercom. Hands up, who's done that" url: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions" locale: "en" author: "Mike Fluff" updated: "2026-02-09" description: "A product team spent seven months building its own Intercom. The seven questions I now ask before anyone writes what they could buy." tags: - "strategy" - "tech" - "ops" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions.md" --- # We spent seven months building our own Intercom. Hands up, who's done that > **In short:** Build what your customers pay you for and buy everything else. One team spent about $45,000 in salaries over seven months on its own support chat, then bought Intercom at about $7,000 a year. After the core question I check the price against developer cost, the API, whether the vendor will survive, data jurisdiction, how custom the process is, and whether to assemble it from ready blocks. 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.1 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*. > **Quick estimate** > > SaaS at $500/mo = $6k/year. Mid-senior developer in EU/US — $80–150k/year. > For a build to pay back, the task can't occupy more than **10% of developer > time over 5 years**. That's rare. **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.** --- > **How I decide in 15 minutes** > > 1. **Core?** Yes → build (or blocks). No → next. > 2. **Does a SaaS cover 80%?** Yes → next. No → build. > 3. **API? Vendor alive? Data in jurisdiction?** All three yes → SaaS. > Any no → build. > 4. **Process heavily custom?** Yes → build or blocks. No → SaaS. --- 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. **[Talk about the architecture call](https://www.mikefluff.com/en#contact)** — If build vs buy has been spinning on your team for three months — come in, let's settle it with arguments. I've seen both scenarios, including shutting down a failed build at a late stage.