The Build Was the Easy Part

There is a particular kind of tiredness that sets in about eighteen months into owning a CRM you did not choose the shape of.

It starts reasonably. Something about the system does not match how your business works, so you file a request. A support person is sympathetic. The request goes to a product team you will never meet, where it joins a queue you cannot see, ordered by priorities that are not yours. Six months later you follow up and learn it is "on the roadmap." Another six months and the roadmap has been reorganized. Meanwhile your team has quietly invented a workaround, and the workaround is now load-bearing.

A client of mine — a financial services firm running about a hundred agents — went through that cycle enough times to stop believing in it. This year they left the CRM they had been paying for and replaced it with software built around the way they actually work. It is live. Their agents use it every day.

The thing I did not expect, and the reason I am writing this, is which part turned out to be hard.

The advice that was right for twenty years

If you had asked me in 2022 whether you should build your own CRM, I would have said no, and I would have been right almost every time. I wrote a long piece a few weeks ago tracing forty years of this same argument, and it concluded that buying is the right call for most businesses. I am revising that here, which is worth saying out loud rather than quietly publishing the opposite.

The reasoning was sound. A CRM is not one feature, it is forty unglamorous ones: contacts, companies, deals, stages, permissions, audit trails, search, imports, exports, notifications, mobile. Every one of them is well understood, none of them is interesting, and all of them take time. You could spend six months building something worse than what a hundred dollars a seat would rent you. The vendors had already paid that cost and were amortizing it across thousands of customers. Renting was obviously correct.

That argument had one quiet assumption inside it: that building the boring forty is expensive. For twenty years it was. It is not any more.

Two things moved, and they help different people

The first change is on the build side. Scaffolding — the contacts, the stages, the permissions, the audit trail — is now genuinely fast to produce. Not free, not thoughtless, but fast. The work that used to consume the first two months of a project now consumes a fraction of it. That does not make software cheap; it makes the generic part of software cheap, which is a different and more useful thing.

The second change is on the rental side, and it went the other way. Per-seat pricing has kept climbing, and it scales with headcount whether or not value does. A CRM seat costs the same for the agent living in the system all day and the one who opens it twice a week to update a field.

Published seat pricing for a serious CRM runs somewhere between about seventy-five and two hundred dollars per user per month depending on tier. You can check that yourself on any vendor's pricing page. The arithmetic is not subtle:

Those are recurring numbers. They arrive again every year, they rise with your headcount, and at the end of five years you own nothing.

Put the two changes together and you get two separate doors into the same conclusion, which matters because they open for different businesses.

Small teams come through the first door. A six-person firm is never going to make the seat arithmetic work — six seats is not real money. But the build cost falling means a genuinely unusual process can now have software shaped around it for a sum that would have been absurd three years ago. They build because it finally got cheap enough.

Larger teams come through the second. At a hundred agents the seat cost is a line item somebody has noticed. They build because renting got expensive enough.

Same conclusion, opposite arithmetic. If you only ever hear the seat-cost version you will assume this is an argument for big companies, and it is not.

Why this client left

The cost was real but it was not the trigger. Three other things were.

Reporting could not answer their questions. The dashboards answered the vendor's questions — the ones every customer has. Anything specific to how this firm judged its own performance meant exporting to a spreadsheet, which meant it happened monthly at best and was stale when it arrived.

The data was effectively trapped. Getting information out to sit alongside their other systems was possible in the way that most things are possible: through an integration that cost more to run than the seats did.

And they wanted control of the layout. This is the one I would have underrated a year ago. They had a clear view of how information should be displayed and how it should move through the system, and no path to getting there except the request queue. At some point the choice stopped being "wait for the roadmap or accept the workaround" and became "wait for the roadmap or build exactly what we want." They picked the third option because the third option had become affordable.

The build was the easy part

Here is the part I would want to read if I were deciding this.

The engineering was not hard. Contacts, records, stages, permissions, search, the audit trail — all of it is solved work, and none of it produced a week I would describe as difficult. If somebody had told me the whole project would come down to a technical problem, I would have expected the migration, and the migration was demanding but tractable.

The genuinely hard part, and the part that created all the value, was deciding what the stages should mean and what an agent should be prompted to do inside them.

Every CRM has stages. Most of them are a vendor's guess at your process, and most teams quietly bend themselves around that guess until the stage names stop describing anything real — at which point a pipeline report is measuring an agent's optimism rather than the state of the business.

What this firm wanted, and could not get from a product, was for the system to be opinionated about their work specifically. Not a board to interpret every morning. A view that tells an agent what to do next on this record, now, and why.

That turned out to be the unlock. An agent opens the system and gets work rather than a picture of work. The stages mean something because the system knows what has to be true before a record can move. Nothing goes quiet unnoticed, because a record that has gone quiet surfaces itself instead of waiting to be remembered.

None of that is an engineering achievement. It is a series of conversations about how a hundred people actually spend their day, converted into software. You cannot buy it, because it is the part that is genuinely yours — and that, rather than the license fee, is the real argument for building.

The client's assessment is that agents are working more files and moving through the stages faster. I am reporting that as their view rather than a measured result, because it is early and nothing has been instrumented yet. When it has been, I would rather publish a number than an impression.

What a migration actually has to carry

If you take one practical thing from this, take this. The reason CRM migrations frighten people is not the contact records. Contacts move fine. What gets lost is everything around them.

• Notes and conversation history. Years of free text an agent wrote about a client, often the single most valuable thing in the old system and the easiest to silently drop.
• Where each record actually stood, and when it got there. If a record lands in the new system at the wrong stage, or loses the date it entered one, every aging report and follow-up is wrong from day one and nobody notices for a month.
• Documents and attachments. Frequently stored by the vendor rather than by you, which is its own small argument for leaving.
• Dead records nobody asks for. Old, lost and declined files. Nobody wants them until compliance, a returning client, or a dispute does.
• Every touch. Texts, calls, emails. The interaction history is the relationship; a contact record without it is a phone number.

All of that is retrievable. Between the outgoing CRM's own API, the telephony and email systems' APIs, and plain scheduled exports where an API does not exist, a cutover can carry the whole history across rather than starting the new system at zero. It is not glamorous work. It is the work that decides whether the team trusts the thing on Monday morning.

What it costs to own one

A custom CRM is not free after launch, and any post that skips this is selling you something.

Somebody has to keep it alive. In practice that has meant the client running it day to day — configuration, users, the ordinary business of operating a system — while changes that need a developer come to me. That split works, but it is a commitment, and it is the honest counterweight to the seat cost you stopped paying.

The version I prefer, where it fits, is handing over enough that the client can make their own changes when the project ends. A build that only its author can touch has replaced a dependency on a vendor with a dependency on a person, and that is not obviously an improvement. If you are evaluating anyone for this kind of work, ask what happens when they are not available. The answer tells you what you are actually buying.

Here is the same judgment as a diagram. It used to be a gauntlet that mostly ended in BUY, because for twenty years that was the right answer. It is a router now, and both ends of it are good outcomes — which is the whole point.

When I would still tell you to buy

I have spent this whole post arguing that the threshold moved. It moved; it did not disappear. I would still tell you to buy if:

• Your process is ordinary. If you sell roughly the way the vendor assumed, their template is not a compromise, it is a head start. Building something that arrives at the same shape by a longer road is waste.
• Integration is the only real problem. If the complaint is trapped data rather than the shape of the system, that is a connector, not a rebuild. Vastly cheaper, and the first thing worth pricing.
• Nobody will own it afterward. Custom software needs a person who cares whether it keeps working. Without that, rent — even if it fits badly, a vendor's maintenance is better than none.

What has changed is not that buying became wrong. It is that "obviously buy" used to be true for nearly everyone, and now there is a real question to answer. The question is no longer can we afford to build this. It is is any part of how we work genuinely ours — and if the answer is yes, the software can now be shaped around it for a price that makes sense.

For twenty years the honest advice was to buy and bend. It is worth actually checking the arithmetic now, because for a growing number of businesses the answer has quietly flipped, and the ones still waiting on a roadmap are paying for the privilege.

If you are somewhere in that decision, the useful thing to bring is the paragraph you would have written in a feature request — the thing your current system will not do, and what working around it costs you in a year. Bring that and we can usually tell in half an hour whether you need a build, a connector, or a better-configured version of what you already own. Here is what that looks like as an engagement, or describe the situation with the button below. I usually reply the same day.