Build inside your stack, or change your stack

Our default, and when we break it

We build inside the tools a client already runs whenever the platform allows it. Familiarity is not a soft benefit. Every new interface costs weeks of adoption, and adoption is where most systems fail.

Some platforms make that impossible. When a tool cannot be reached properly from outside, building around it produces something fragile that breaks the first time a vendor ships an update.

In that case we say it plainly. Changing the tool now is cheaper than automating around it for three years.

The four questions that settle it

1. Can you get your data out, on demand?

Not a monthly CSV. A proper interface that returns current records when something asks for them. If the only export is a button a human clicks, every system you build has a person inside the loop forever.

2. Can something outside the tool make a change inside it?

Reading is half the job. A system that can see your orders but cannot update one is a reporting layer, not an operation.

3. Does the tool tell you when something happens?

Without a webhook or an event feed, your automation has to poll. Polling every fifteen minutes turns a five minute response promise into a twenty minute one, which quietly matters in sales.

4. Is the vendor building or coasting?

Check the changelog. A platform that shipped nothing for eighteen months will not suddenly grow the interface you need. That is a migration you are going to do eventually, so timing is the only real question.

Three yes answers and we build inside your stack. One yes and you have a migration on your hands, whether or not you schedule it.

What switching actually costs

Vendors quote you the licence. The licence is the smallest line.

That is a real shape from a 55 person company moving CRM. The licence was $14,000. Migration and data cleanup came to $21,000, mostly because eleven years of records had four spellings of the same client.

Then 310 hours of team time, and a measurable dip in output for about seven weeks. Total cost of change: around $60,000 against a headline of $14,000.

Now the other column

Staying was not free either. The old CRM had no event feed, so lead notification ran on a fifteen minute poll. Reps averaged a 40 minute first response against a target of five.

Using that company's own pipeline figures, the gap was costing roughly $9,000 a month in deals that went to whoever answered first. Twelve months of staying cost more than the migration did.

That is what made the decision obvious. Not the feature list, the arithmetic.

The middle path most people miss

You rarely have to move everything. Plenty of companies keep the system of record and move only the layer that is blocking them.

• Keep the accounting platform, move document generation and approvals out of it.
• Keep the CRM as the client record, run sequencing and routing in a layer that can actually be triggered.
• Keep the industry specific tool nobody can replace, and put a small database beside it for the parts it cannot hold.

This is unglamorous and it works. A vertical tool built for clinics or law firms usually holds compliance you do not want to rebuild. Automating alongside it is the sane answer.

When we argue against a big rebuild

Owners sometimes arrive wanting a bespoke system to replace five tools. Occasionally that is right. Usually it is an expensive way to avoid a smaller decision.

A custom platform means you now maintain software forever, and the original bottleneck often survives the rebuild untouched. We will build it if a client insists, priced honestly, but as consultants we say what we think first.

How to run this test on your own stack

Take your five most important tools. Give each one a yes or no on the four questions above, then count.

1. Four yes answers: automate inside it and stop worrying.
2. Two or three: build inside it, but keep your data mirrored somewhere you control.
3. One or none: price the migration now, while the decision is still yours to time.

Do this before you buy any automation work. It changes what is worth building, and it occasionally saves the whole budget.

Questions to ask a vendor before you sign

Sales engineers answer feature questions beautifully. Ask these instead, then listen for the hesitation.

• Can I read and write every field through your interface, or only the ones on your published list?
• Do you send an event when a record changes, or do I have to check on a timer?
• What is the rate limit, and what happens on the day I go past it?
• If I leave in three years, in what format do I get my data back?

The last question is the most revealing. A vendor confident in the product answers immediately, because they do not expect you to use it.

Timing the move

Never migrate in your busiest quarter, and never during a change of leadership. Beyond that, earlier is cheaper, because every month adds records to clean and habits to unlearn.

We usually split it. Move the system of record first, run both for four weeks with a hard switch off date, then rebuild the automations once the data has settled.