Turned an AI-generated CRM into one that could survive real customers

The Client came to us with a demo that looked ready — and a handful of bugs they wanted fixed.

They'd built an AI-powered CRM for B2B sales teams — lead management, email outreach, and LinkedIn automation, with AI generating much of the outreach content itself — almost entirely using AI coding tools. It demoed well: a dozen backend services written in Go, Python, and TypeScript, a multi-tenant PostgreSQL database, and live integrations with HubSpot, Stripe, Twilio, and AWS. By most measures, it looked like a finished product.

During one of the demos, a few bugs surfaced — nothing that seemed unusual for a product at this stage. The Client asked us to take a look.

That's where the real story starts. What began as a short bug-fixing task turned into something much bigger the moment we started tracing why those bugs existed. They weren't isolated mistakes — they were symptoms. Underneath the surface, we found a system that had never been tested against the conditions real production traffic creates: real failures, real concurrent users, real data at scale. The deeper we looked, the more of the platform turned out to be built the same way — functional on the surface, unproven underneath.

We proposed stepping back to run a full audit before continuing to patch things one at a time. The Client agreed. What we found became the real scope of the engagement.

What "feature-complete" was hiding

The product couldn't stand on its own two feet

Software can work perfectly and still be quietly dependent on a single point of failure. In this case, the CRM used HubSpot's own ID numbers — HubSpot being the third-party CRM platform it integrated with — as its own core identifiers: companies, leads, and contacts were all keyed off IDs that belonged to HubSpot, not to the product itself. No company or lead could exist in the system without first passing through HubSpot. That same decision had been repeated across roughly eight different backend services, each with its own hand-built integration.

It's the kind of shortcut that's invisible in a demo and expensive months later. If a CRM vendor changes its pricing, has an outage, or a customer wants to switch providers, the entire product's foundation is exposed — and most teams don't find that out until it's already a problem.

Failures that never told anyone they'd happened

The more concerning pattern was software that reported success while quietly doing nothing. A database change made in one service was never propagated to the other services reading that same data — so ordinary, everyday actions, like opening a lead's details or pulling up enriched contact information, started silently failing. No errors. No alerts. Nothing visibly wrong. The team didn't find out until customers did, and said something.

That's the most dangerous kind of failure there is. It doesn't erode trust loudly — it erodes it invisibly, one unnoticed failure at a time, until someone finally asks why something that should have worked, didn't.

The parts nobody thinks to ask an AI for

Some of the biggest gaps weren't bugs at all — they were entire categories of production concern that simply hadn't been built. There was no way to monitor the system's health, so problems were only discovered after a customer ran into them. There was no access control: any logged-in user had full access to their company's data, with no way to restrict it. There was no audit trail — no way to answer "who changed this, and when" after the fact.

These aren't luxuries. They're the difference between software a team can trust with real customer data at real scale, and software that only works because nothing has gone wrong yet.

The same bug, living in four places at once

Because the underlying logic was never centralized, fixing something in one place often didn't fix it everywhere. Core logic — authentication, database connection handling, and more — had been independently rebuilt across multiple services in multiple languages instead of shared, with each copy quietly carrying its own slightly different version of the same problem. Patch it in one service, and the same bug was often still live in three others.

That's exactly why a handful of visible bugs couldn't be treated as a handful of visible bugs. Fixing what's in front of you doesn't fix what you can't see — and in a system built this way, most of it you couldn't see.

How we actually approached it

We didn't start fixing things immediately. Before writing a line of code, we ran a systematic, documented audit across every service in the platform, cataloguing every issue we found and ranking it by real-world severity — critical, high, medium, low — so nothing got missed and nothing got fixed out of order.

One moment from that audit stuck with us. A routine billing hiccup on a single customer's account had caused the system to retry the same failed operation thousands of times in under half an hour — and every one of those retries fired an internal alert. The team had been quietly flooded with noise about a problem only the customer could actually fix, and the customer themselves had never been told anything was wrong. Nobody had designed for what happens when a retry doesn't know when to stop. It simply hadn't come up — until it did, on a real account.

Not everything we found needed the same treatment. Some services just needed the vendor dependency removed — the underlying logic was sound. A couple needed to be rebuilt outright, because the foundation itself was wrong, not just the implementation. Making that call correctly, service by service, is most of what this kind of work actually is.

What changed

The architecture no longer depends on a single vendor: the product now owns its own core identifiers and can support additional CRM integrations rather than being structurally married to one. The failure modes that used to fail silently now surface, get logged, and get flagged instead of disappearing. The production fundamentals that were missing — access control, monitoring, audit logging, credential hygiene, and hardened data handling — are now in place. And the logic that used to live in three or four slightly different copies now lives in one shared place, so a fix actually holds everywhere it's needed.

Where it stands now

The platform is live in production today, built to withstand exactly the kind of failure conditions that used to reach customers unannounced. The bugs that started this engagement are gone — and so are the hundred other things nobody was watching for until we went looking.

Here's the pattern worth naming directly: the bugs the Client originally asked us to look at were the visible five percent. The audit found the other ninety-five. Most AI-built products carry that same hidden ninety-five percent — they just haven't had a bug surface yet to force someone to go looking.

If you've built something with AI coding tools and it's never had a full audit, there's a good chance you don't know what's underneath it either.

We'll tell you — for free

Just hit us up at contact@graylining.com