Every growing B2B team hits the same wall. Pipeline lives in a spreadsheet, follow-ups live in someone's memory, and the founder asks "where are we with this account?" three times a week. The obvious answer is to buy a CRM. We looked at the usual options and kept running into the same problem: they were designed for teams far larger than ours, with processes we didn't have.

So I tried something that would have been unrealistic a couple of years ago for someone who isn't a full-time developer. I built our CRM myself, with Claude Code.

Why build instead of buy?

This isn't an argument against commercial CRMs. If you have a large sales team, integrations everywhere and an admin to run it, buy one. But our situation was different:

  • Long, multi-stakeholder deals. Selling to OEMs means engineering, IT, procurement and leadership all have a say. Off-the-shelf pipelines assumed a simpler path.
  • Few deals, high value. We needed depth on each account, not volume tooling.
  • We wanted AI inside the workflow, not bolted on as a premium add-on.

The real question wasn't "build or buy". It was "what is the smallest thing that would make our sales process visible and reliable?"

What I built first (and what I didn't)

The temptation with a blank page is to rebuild everything. I made myself start with only four things:

  1. Accounts and contacts, with the role each person plays in the buying decision.
  2. Pipeline stages that match how OEMs actually buy, from first conversation to technical evaluation, commercial discussion and closure.
  3. Follow-up reminders, because most deals don't die from rejection; they die from silence.
  4. A live dashboard so the founders could see pipeline without asking anyone.

Everything else, like email sync, forecasting and fancy reports, waited until the basics proved themselves. Today the system tracks more than a thousand contacts across 250+ accounts, and the spreadsheet is retired.

How building with Claude Code actually works

I describe what I need in plain language, Claude Code writes and edits the code, and I test it against how we really work. When something breaks, I explain the problem and we fix it together. The skill that matters most isn't programming. It's being precise about the business process.

The hardest part of building a CRM isn't the code. It's deciding what your sales process actually is.

A few practical lessons:

  • Write the process down before you build. If you can't describe your stages in a sentence each, the tool won't fix that.
  • Build in small pieces and use them immediately. Real usage finds problems that planning never does.
  • Keep the data clean from day one. One messy import can undo months of trust.
  • Own your backups. When you build it, you're responsible for it.

Where AI makes a home-built CRM better

Owning the system meant we could wire AI into the places that mattered:

  • Account briefs generated before demos, summarising history and open questions.
  • Cross-sell signals: an analysis of which customers aren't yet using which products, which surfaced 30+ expansion opportunities.
  • Follow-up drafts that a person reviews and sends, so nothing goes out unchecked.

Should you build your own?

Build if your team is small, your sales motion is unusual, and someone on the team is willing to own the tool. Buy if you need many integrations, have strict compliance needs, or nobody wants to maintain software. There is no shame in either answer.

The real payoff

The biggest change wasn't technical. Once pipeline was visible, conversations with the founders shifted from "what's happening?" to "what should we do next?" That's what a CRM is for. Ours just happens to be one we understand completely, because we built it.