Every agency owner I talk to thinks they're the exception.

"Our workflow is too unique for a CRM product."

They almost never are.

I've heard this from contractors, lawyers, photographers, estate planners, and hundreds of small business owners across my groups. It's almost always the same five workflow quirks dressed up in different industry vocabulary.

And here's the awkward part... I used to believe it too. I spent 800+ hours over the last several months building my own CRM from scratch. So I'm not writing this from a high horse. I'm writing it from the inside of the actual project.

Let me walk through what I've learned.

The "we're unique" myth

Your business is unique. Your workflow probably isn't.

When someone tells me their needs are too custom for off-the-shelf software, I ask them to describe the workflow in writing. Not the marketing version. The actual one. Lead comes in, goes here, gets tagged this way, gets contacted on this cadence, gets handed off here, gets followed up on like this.

Nine times out of ten the workflow fits a standard pipeline with maybe two custom fields and a slightly weird tag structure.

The tenth time? Sure. Genuinely custom. We'll get to that.

But the other nine times the problem isn't that no CRM fits. The problem is the owner has never actually written the workflow down, and the off-the-shelf tools look intimidating because they expose a hundred features the owner doesn't need.

Five features every team thinks they need that they don't

Here's the list I see over and over:

1. A "fully custom" deal pipeline. Every CRM on earth has custom pipelines. You don't need a custom build to get this. You need 30 minutes with the pipeline settings.

2. A bespoke automation engine. You think you need If-This-Then-That with 47 branches. You actually need three automations: new lead notification, no-response follow up at day 3, and won-deal handoff. That's it. Every CRM does this.

3. Industry-specific dashboards. You don't need a dashboard. You need to know your weekly leads and your monthly close rate. That's a screenshot you take once a week, not a BI tool install.

4. Tight integration with one specific tool. Usually QuickBooks or a niche scheduling app. Zapier or Make.com handles 95% of these. The other 5% is solved by exporting a CSV once a week, which is FARRR less painful than building integration code.

5. A "client portal." Nobody uses these. I've sold and built more than I can count. Your clients want a text message and a paid invoice link, not a login.

Every time someone insists on these five, they're describing a SaaS that already exists. They just haven't tried hard enough to find it.

Three features they actually need that no SaaS provides

This is where it gets fun.

1. Ownership of the data and the code.

Here's a question that wrecked my entire business model two years in. A client asked me "what happens if you die?" Their whole digital operation was running through my agency's stack. My credit card paid the subscriptions. My subcontractors had no direct contact with them. If I got hit by a bus, my clients were stuck.

I spent the next two months rebuilding the agency from the ground up. New systems, new portal, new community, new service structure. The thing that drove all of it was the realization that I didn't actually own what I was selling. I was renting it and reselling the rental.

No SaaS solves this. By design. They keep you on the treadmill because the treadmill IS the business model.

2. Pricing that doesn't punish growth.

The CRM industry priced itself around "per seat per month" because it's a license to print money. The moment you grow, your cost grows. The moment a client adds a user, your margin shrinks.

If you run an agency reselling CRM access, you've felt this. Your client adds three users and suddenly your $97/mo subscription is $297/mo. You either eat it or you pass it on and look greedy.

A flat-priced or source-code-owned setup kills this. Nobody sells it because nobody making subscription money WANTS to sell it.

3. The ability to actually change the software.

Every business hits the wall eventually. The CRM does 90% of what you need. The other 10% requires a feature request that gets ignored, a workaround that breaks every six months, or a third-party tool you bolt on with duct tape.

If you own the source, you change the software. If you don't, you change your business to fit the software.

Why forking solves the second list

Forking, or buying source code outright, is the middle path almost nobody talks about.

You don't build from scratch. You don't rent forever. You start from a working codebase and you own it.

Cost-wise it's a one-time investment instead of a forever subscription. Capability-wise you skip the 18 months of base CRM construction and start adding the parts that matter to YOU. Risk-wise you keep working software running while you customize the edges.

The case against forking is real though, and worth naming. You inherit someone else's decisions. The architecture might not be how you'd build it. The dependencies are theirs, not yours. You have to actually be able to read and modify code, or hire someone who can.

For most agency owners and small biz owners I talk to, those tradeoffs are FARRR easier to live with than either of the alternatives.

The honest case for build-from-scratch

It exists. It's rare.

Build-from-scratch makes sense when:

• Your workflow genuinely doesn't map to existing CRM concepts. Not "I want it MY way" but "the existing data model literally can't represent what I do."
• You have engineering capacity in-house and that capacity isn't better deployed elsewhere.
• You're building something you intend to sell, not just use.
• The time-to-money tradeoff is worth it. CRM-from-scratch is at minimum 6 months of full-time work to reach feature parity with the cheapest off-the-shelf option. Probably more.

I built from scratch. I'll be straight with you: I did it partly because I wanted to sell the codebase, partly because I'm stubborn, and partly because I'd already gone deep enough into the existing tools to know exactly what I wanted to change.

If you don't have at least two of those three motivations, build is the wrong answer.

So where does this leave you?

If you're an agency or small business owner staring at your CRM bill and wondering if you should build your own, the answer is almost always no.

The answer is almost always: write down your actual workflow first, evaluate three off-the-shelf options against it, and pick the cheapest one that covers the workflow.

If that fails because of the data, pricing, or customization problems I listed above, look at source-code or fork options before you write a single line of original code.

And if even THAT fails, then maybe you build. Eyes open. Big budget. Long timeline.

Where do you fall on this... build, buy, or fork? Genuinely curious.