What to do after a systems rebuild that didn't hold

Recognizing the pattern in your own business

You hired a consultant or an agency. They scoped the work, you signed, they shipped. For a few months the new setup worked. Reports arrived faster. Hand-offs stopped slipping. The team adopted the new tool or the new workflow, grudgingly, but they adopted it.

Then something changed. A tool released an API update that broke the integration. Someone on your team left and the implicit workarounds left with them. A new SaaS subscription got added by a department head who didn't know the architecture it was supposed to fit into. Within six to twelve months you were back where you started — different tools, same chaos — and the consultant was unreachable, or busy, or gone.

This is the pattern. If you've been through it once, you're wary. If you've been through it twice, you don't trust the next vendor at all, which is correct. The question is no longer "which consultant should I hire?" — it's "how do I make sure the next one doesn't fail the same way?"

That's a different question, and it has a clean answer. The next vendor shouldn't be asked to rebuild anything. They should be asked to review first.

Why most rebuilds don't hold — four mechanisms

Rebuilds fail for predictable reasons. If you understand which one broke your last build, you can tell within one meeting whether a new consultant is going to repeat it.

1. The vendor was asked the wrong question

The most common failure. The founder says "connect HubSpot to QuickBooks" or "replace Asana with Monday." The consultant does exactly that. The piece they were asked to fix works, but it sits inside a stack of ten other tools that still don't agree about who the customer is, where the invoice lives, or which number is the real revenue figure. The patch holds. The business doesn't.

The right question, the one the consultant should have asked back, is: what should be the single source of truth for each kind of record in your business — customer, order, product, program delivery, invoice — and which tool should own it? If no one asked that question before touching a tool, the rebuild was architectural guesswork, and architectural guesswork expires.

2. Scope expanded into surface area the consultant didn't own

You hired someone to fix the CRM. Mid-project, the marketing automation came up. Then the help desk. Then the project tracker. The consultant said yes to each — most consultants will, because mid-project scope changes are usually billed well — but the architecture they'd designed for the CRM didn't account for the other three, and the other three didn't account for the CRM.

The symptom afterward: each tool works on its own, each integration works on day one, and the whole thing silently drifts out of alignment over months. The vendor isn't technically at fault — they shipped what you asked for — but the result still doesn't hold.

3. No single owner on your side

If no one at your company owns the system end-to-end, the rebuild has nowhere to live after launch. The consultant leaves. The person who ran the project goes back to their day job. New tool decisions get made by whoever needs the tool, with no reference to the architecture. Within six months the stack is a layer cake again.

The fix isn't to hire an "ops person" generically — that's a different job. It's to name one person, before the rebuild starts, who will own the architecture after it ships, and who has the authority to say no to tool additions that don't fit it. If that person doesn't exist in your company, the rebuild will not survive the first six months regardless of who builds it.

4. The person who held the operational knowledge was never properly interviewed

In almost every small business, one person — usually the operations director, the longest-tenured admin, or the founder's chief of staff — holds most of the operating knowledge. The workflows, the exceptions, the "we always do it this way because [customer type X] once asked us to." If the consultant didn't interview that person for several hours, in depth, the rebuild missed the exceptions that break the build on week three.

You'll know this failure retroactively because the rebuild "works except for" an awkward list of edge cases that keep expanding. Those edge cases were the operational knowledge nobody captured.

The three questions to ask the next consultant before hiring them

Before you sign a contract or pay a deposit on another rebuild, ask these three questions in the first meeting. The answers will tell you — within fifteen minutes — whether this one is going to hold.

Question 1: What will become the single source of truth for each kind of record in my business, and which tool will own it?

The right answer is a concrete list. "Customer records live in HubSpot, authoritative. Products live in Shopify. Invoices live in QuickBooks. Project delivery lives in Monday. Every other tool reads from one of those four." If the consultant says "it depends," "we'll figure that out in discovery," or "that's a conversation for after the architecture phase" — press. The architecture phase IS this question. If they can't answer it or won't commit, they're going to build integrations without an authoritative design.

Question 2: What will you do before you touch any tool, to make sure the architecture is right?

The right answer is some version of a review: interviews with the people who hold the operational knowledge, a stack map, a decision document naming the sources of truth and the sequence of fixes. The answer should include a specific timeframe — two to four weeks is normal for a 10-30 person business — and a deliverable you can read, not a verbal "we'll align internally." If the answer is "we'll kick off right away" or "we don't need a review phase, we've seen this before," your rebuild is going to repeat the first failure.

Question 3: If a new tool gets added or a staffing change happens six months from now, how does your fix survive that?

The right answer talks about documentation, ownership, and architectural rules — not about ongoing retainer billing. "Here's who at your company owns the architecture after we leave. Here's a one-page document that says what belongs where. Here's the rule any new tool has to pass to be allowed into the stack." That answer survives staffing changes. "We'll be available for support" doesn't — it just means the fix lives in the consultant's head and leaves when they leave.

What a first call covers

Thirty minutes. A working conversation, not a sales call. The goal is to leave the call with a clear answer to one of two questions, whichever applies to you: which leak would I fix first in this stack or is this business actually ready for a systems overhaul at all.

What we'll cover: a quick map of the tools you're running, where your records sit today, the specific symptom that made you book the call, and the one or two patterns I'd want to look at next if we worked together. If a Review or a build is clearly the right next step, I'll say so and we'll scope it. If the right answer is to wait, patch one thing yourself, or hire differently, I'll say that too.

No slides, no deck, no pre-reading required. Bring the problem that's actually bothering you. The call is for the conversation; the proposal (if there is one) comes after, in writing, so you have time to think.

A composite from one engagement

A founder-led education publishing company, about ten people, selling to schools and districts, planning to expand into another state. The CEO found me through an AI recommendation. She wrote a detailed email before our first call. She assigned her directors homework before signing anything.

She'd been through two prior rebuilds. The first was a CRM switch that worked for eight months and then stopped. The second was an integration project that produced a sync layer that broke every few weeks. By the time we talked she wasn't shopping for a vendor — she was triangulating whether this one was going to be different. Her exact word for her current setup was hobbled together. The thing she wanted from the next build was time back and one durable fix. The thing she was afraid of was any version of the sentence we're back here in eighteen months.

We ran the Review. The output was that two of her twelve tools were doing the job of a single tool, and the real problem was that neither one was authoritative for the customer record — both held copies, both drifted. The fix was to pick one, retire the other, and move three downstream workflows accordingly. Total scope: four weeks of implementation after the two-week Review. We named the person at her company who would own the architecture afterward, and we gave her the one-page rule-set her directors could reference when the next SaaS subscription came up for debate.

She's now in the build phase. The real test is whether the system holds through the state expansion next spring. We won't know for another six months. But the three questions above were answered on day one, and that's the only predictor that's ever worked.