Every CRM rots. Contacts change jobs, forms get filled with junk, the same company lands in your database three times under three spellings, and six months later your reports quietly stop meaning anything. Most teams treat this as a chore — a quarterly cleanup someone dreads, or a paid SaaS tool bolted on to paper over the mess. For a B2B client of ours, we did something different: we built a small data-hygiene bot on top of the HubSpot API and GitHub Actions that runs on its own, every night, for essentially the cost of nothing. Here’s what it does, why we built instead of bought, and where that line actually falls in 2026.
RevOps · Data Hygiene
Why Does CRM Data Hygiene Keep Breaking?
Because dirty data is not an event — it’s a constant leak. Every new lead, every integration, every manual edit is a chance for a duplicate, a malformed email, an empty lifecycle stage, or a country field that says «USA», «U.S.» and «United States» in the same list. The damage is quiet but expensive: sales chases the same account twice, automation fires on the wrong segment, and the dashboards leadership trusts are built on sand.
The instinct is to lean on the CRM’s built-in tools, and they help — up to a point. HubSpot auto-deduplicates contacts by email and companies by domain, and its Manage Duplicates tool surfaces likely matches. But the native tool is capped — roughly 2,000 suggestions on Professional, 5,000 on Operations Hub Pro, 10,000 on Enterprise — and, critically, companies created through the API are not deduplicated by domain at all. So the moment you have real volume, or any integration writing records in, the native cleanup is structurally behind. That gap is exactly where a paid deduplication SaaS steps in — and where the build-versus-buy question gets interesting.
Build or Buy? The 2026 Line Has Moved
For years the answer was obvious: buy. Building internal tooling meant hiring developers, standing up infrastructure, and owning maintenance forever — not worth it to merge duplicate contacts. But two things changed. Natural-language coding collapsed the cost of writing and maintaining a focused script, and connector APIs plus free automation runners removed the infrastructure entirely. The line between build and buy moved, and a lot of ops teams are still drawing it where it sat in 2022.
The useful way to decide is a simple 2×2: impact on revenue against effort to build and maintain. Keep buying where the vendor’s value is proprietary — your core CRM, email deliverability, third-party intent and contact data. You are not going to out-build HubSpot. But for configurable workflow — the rules that decide what «a duplicate» means for your business, which fields to standardise, when to flag a stale record — the buy case is shrinking fast, because those rules are specific to you and cheap to encode. Deduplication logic is the textbook example: high enough impact to matter, low enough effort to own. We’ve made the same argument about owning your integration layer through the marketing connector landscape and your customer data through first-party data infrastructure — a hygiene bot is the same principle applied to data quality.
Could a well-configured native feature or a $50/month tool solve 90% of it? If yes, buy it. Build only when your rules are genuinely yours, the volume breaks the native caps, or you need it running unattended on a schedule no SaaS plan gives you. «We can code it now» is not the same as «we should.»
How We Built It: HubSpot API + GitHub Actions
The architecture is deliberately boring, which is the point. There is no server, no hosting bill, and nothing to babysit. The whole thing is a script in a private GitHub repository that runs on a schedule through GitHub Actions — the same free CI runner developers use to test code, repurposed as a nightly cron job. Every night it wakes up, talks to HubSpot through the CRM API, does its work, and goes back to sleep.
Concretely, the bot does four jobs on each run. First, deduplication: it pulls records in batches, groups them by normalised email and domain (plus fuzzy matching on name and company for the cases HubSpot’s exact-match logic misses), and merges or flags the collisions using its own rules — not the native cap. Second, standardisation: it rewrites the messy free-text fields into a controlled vocabulary — country, job title, lifecycle stage, industry — so segmentation stops leaking. Third, validation: it flags malformed emails, missing required properties, and records that have gone stale past a threshold. Fourth, reporting: it posts a short summary — how many merged, standardised, flagged — to a Slack channel, so the team sees the CRM getting cleaner instead of wondering if anything happened.
Two engineering choices made it safe enough to run unattended. It respects the API rate limits and runs in batches, so it never hammers the portal. And every destructive action — every merge — is logged and, in the early weeks, ran in a dry-run mode that only reported what it would do, so we could tune the matching rules against real data before letting it write. A hygiene bot that merges the wrong records is worse than dirty data; the guardrails matter more than the clever part.
A nightly script on an API and a free CI runner now does what used to require a paid SaaS subscription — because the value was never the infrastructure, it was the rules that define clean data for your business.
You own those rules. That’s the part worth building.
Is your CRM data quietly breaking your reporting?
I help B2B teams audit their CRM, fix the data model, and automate the hygiene — whether that’s the right native setup, the right tool, or a custom bot like this one. The goal is the same: reports you can trust.
What We Learned — and When Not to Build This
The bot works, the client’s reports are trustworthy again, and the running cost rounds to zero. But the more useful lessons are the caveats. Start in dry-run and stay there longer than feels necessary — the matching rules are where all the risk lives, and real data always surprises you. Log everything and make merges reversible where you can; a good audit trail is what lets you sleep. And solve the model, not just the symptom — if bad data keeps arriving, fix the forms and integrations creating it, or the bot just becomes a permanent mop.
Just as important: know when not to build. If your volume sits comfortably under the native caps, use HubSpot’s tools and move on. If a maintained app solves it for a few dollars a month and you have no unusual rules, buy it — owning code you don’t need is its own kind of debt. Build only when the impact is real, the rules are genuinely yours, and you have someone who can maintain it. For this client all three were true, so a bot was the right call. For the next one it might not be, and saying so is the consulting.
The wider shift is the one running under most of what changed this year: AI and open APIs keep making the doing cheap, which moves the advantage to judgement — knowing which problems deserve a custom build and which just need the boring, already-existing fix. A hygiene bot is a small example of a big pattern: the tools to build your own leverage are now within reach of a one-person consultancy, if you know where to point them.
Want clean, trustworthy CRM data without babysitting it?
I help consultants, agencies and B2B teams design the right hygiene setup for their CRM — native configuration, the right tools, or a custom automation like this one — so your data stays clean on autopilot and your reports finally tell the truth.
