Operations · Strategy
The average stack isn’t designed. It accretes — one tool per problem, each bought by a different person, none of them ever removed. Here’s how to build one deliberately, and how to dismantle one that already happened to you.
Nobody sets out to build a bad marketing stack. What happens is that a specific problem arrives on a Tuesday, somebody finds a tool that solves it, the trial is free, and by the time anyone asks whether it should exist there are eleven months of data in it and a workflow depending on it. Repeat for four years.
The result is recognisable. Twenty-odd subscriptions. Three tools that overlap almost entirely. Two nobody has opened since the person who bought them left. A customer record that exists in four systems with four different versions of the truth. And an annual spend that, when totalled honestly for the first time, produces a silence in the room.
The failure isn’t that any individual purchase was wrong. Each was defensible when made. It’s that a stack has properties the individual tools don’t — integration surface, data consistency, maintenance load — and nobody was responsible for those.
The Question That Should Precede Any Purchase Ask it out loud, in a meeting
Not “does this tool do something useful.” Nearly every tool does. The question is:
What decision will this let us make that we cannot make today?
If the answer is vague — better visibility, deeper insights, more control — you are buying a feeling rather than a capability. If the answer is specific, name the decision, and then ask the follow-up: and are we resourced to act on it? A tool that surfaces information nobody has time to act on has added cost and nothing else.
The second question, equally underused: what does this replace? If the answer is nothing, the stack has grown, and growth needs justifying rather than assuming. Every tool added multiplies integration points, not adds to them.
The Layers, and Why Order Matters Build from the bottom
A stack is not a list. It’s a dependency structure, and building it out of order is what produces the fragile ones.
Layer one: the system of record. The single place a customer definitively exists. For e-commerce, your store. For B2B, your CRM. For a publisher, your subscriber database. This is the layer everything else references, and there must be exactly one of it. Most stack pathology traces back to organisations that have two and treat both as authoritative.
Layer two: collection. How data gets in. Your website, forms, analytics, tag management. If this layer is wrong, everything above it is confidently wrong, which is worse than being empty.
Layer three: activation. Where you act on the data. Email platform, ad accounts, whatever reaches customers.
Layer four: measurement. Reporting, dashboards, attribution. Deliberately last, because you cannot meaningfully measure a system whose lower layers are inconsistent — you’ll build beautiful reports on data nobody trusts, which is the most common expensive mistake in this whole domain.
The rule that follows: fix downward, never upward. When a number looks wrong, the instinct is to add a reporting tool. The cause is nearly always in layer one or two.
The Overlap Audit Where the money actually is
Before considering what to add, map what you have against what it does. Not by product name — by function.
List every tool and, next to it, every job it performs. Then look for functions appearing more than once. In every stack I’ve audited, the same overlaps recur:
Email sending in the email platform, the CRM, and the e-commerce platform. Three systems capable of the same job, usually with three different suppression lists, which is a compliance problem as well as a cost one.
Forms and landing pages in the website builder, the email platform, and a dedicated landing page tool. Almost always one too many.
Analytics in GA4, the e-commerce platform, a heatmap tool, and a dashboard product, each reporting different session counts.
Automation in the CRM and the email platform, with sequences in both and no clear rule about which owns what.
Consolidating overlaps is the highest-return exercise available, because you remove the subscription and the reconciliation work and a category of data inconsistency simultaneously. It’s also the least popular, because whoever chose each tool has to accept that theirs is going.
Integration: The Cost That Doesn’t Appear on Any Invoice Quadratic, not linear
Here’s the arithmetic that explains why stacks collapse.
Five tools have up to ten possible connections between them. Ten tools have forty-five. Twenty tools have a hundred and ninety. Integration complexity grows roughly with the square of the tool count, while the value of each additional tool is at best linear and usually declining.
You won’t build every possible connection. But every connection you do build is code that can break, a mapping that can drift, and a thing that needs testing whenever either end updates. Middleware — the connector platforms that promise to link everything to everything — makes connections cheaper to create, which is genuinely useful and also accelerates exactly the accumulation that causes the problem.
Three practical rules:
Prefer native integrations over middleware. A vendor-built connection is maintained by someone with an incentive to keep it working. A connector you built is maintained by you, forever, silently, until it fails.
Document every connection. One page: what talks to what, in which direction, carrying which fields, and who owns it. This is unglamorous and it is the difference between a stack you can change and one you’re afraid to touch.
Test integrations on a schedule. Connections fail silently. A field mapping that broke in April looks identical to a field nobody filled in. Quarterly verification, on the calendar.
“Five tools have ten possible connections. Twenty have a hundred and ninety. The tools scale linearly and the complexity doesn’t.”
The Single Source of Truth Problem Where most stacks actually break
Almost every serious stack pathology reduces to one thing: the same fact exists in several places and they disagree.
A customer’s email address in the store, the CRM and the email platform, updated in one and not the others. An order total that includes tax in one system and excludes it in another. A conversion counted once by the ad platform, once by analytics, once by the store, arriving at three different figures for the same week.
The technical fix is a declared system of record per data type, with defined write and read directions. The harder part is organisational: someone must decide, and the decision will be unpopular with whoever owns the system that loses.
Three rules that resolve most of it:
One writer per field. If two systems can both edit a customer’s email address, they will diverge. Pick one as authoritative and make the other read-only for that field, even where the tooling permits otherwise.
Define your terms once, in writing. What counts as a customer, an order, a lead, a conversion. Sounds trivial and is the reason three people report three different numbers — they’re each counting something slightly different and all of them are right.
Reconcile on a schedule. Monthly, compare the key figures across systems and investigate the gaps. Divergence is normal; unexplained divergence is a fault. Catching it monthly is routine maintenance and catching it in a board meeting is not.
What a Sane Stack Looks Like, By Size
| Stage | Tools | What you need | What to resist |
|---|---|---|---|
| Solo / pre-revenue | 3–4 | Website, analytics, email, payments | Anything described as a platform |
| Small business | 5–7 | Add a CRM or store, tag management, a scheduler | Attribution tools, CDPs, dedicated landing page products |
| Growing team | 8–12 | Add ad platforms, reporting, support, a data warehouse | A second tool for anything you already do |
| Established | 12–18 | Add experimentation, verification, deeper BI | Buying rather than consolidating |
| Anyone, at any size | Under 20 | Documented integrations, one system of record | Tools nobody has opened in 90 days |
Build, Buy, or Do Without A decision rule
Three options exist for every capability and most organisations only seriously consider one.
Do without is the option nobody evaluates and frequently the correct one. The question isn’t whether a capability would be nice — it’s whether its absence is currently costing you something identifiable. A great deal of martech solves problems that would resolve themselves if someone spent an hour on the underlying process.
Buy is right when the capability is standard, someone else maintains it, and your version wouldn’t be differentiated. Email sending, payments, analytics collection, support ticketing. Nobody wins by building these, and organisations that do are usually solving an ego problem rather than a business one.
Build is right in one narrow circumstance: when the thing is genuinely specific to how your business works and no product fits without contorting your process to match it. A bid optimisation rule reflecting your actual margin structure, a reporting join no vendor’s schema anticipates, a workflow encoding something you do that competitors don’t.
The failure mode on each side is symmetrical. Buying something specific to you means bending your operation to fit a tool. Building something standard means maintaining forever what you could have rented for a modest monthly fee.
One test that cuts through it: if this capability disappeared tomorrow, would customers notice? If yes, it’s probably core and worth owning. If only you would notice, buy the cheapest adequate version and stop thinking about it.
The Costs That Don’t Appear in the Subscription Where budgets actually go wrong
Implementation. Routinely two to five times the first year’s licence for anything substantial. A CRM at $3,000 a year that takes six weeks of someone’s time to configure properly cost considerably more than $3,000.
Data migration. Always worse than estimated. Field mappings don’t align, historical data has quality problems nobody knew about, and the cleanup is discovered mid-migration rather than planned.
Training and ramp. A tool nobody knows how to use produces no value while producing full cost. This is the mechanism by which shelfware happens — not that the tool was bad, but that nobody ever got over the learning curve.
Per-seat creep. Seat-based pricing scales with headcount rather than with value received, and licences accumulate for people who left.
Exit cost. How hard is it to get your data out in a usable form? Ask before signing, not when leaving. A tool with poor export is a tool you’ll keep paying for after you’ve stopped wanting it, which is a business model rather than an oversight.
The Warehouse Question When it’s genuinely time
At some point somebody proposes a data warehouse, and the answer depends entirely on whether you’ve hit the actual triggering condition.
The condition is not size. It’s whether you need to join data that lives in different systems in order to answer questions that matter. Customer support tickets against churn. Ad spend against lifetime value. Content consumption against subscription renewal. If those questions are business-critical and currently unanswerable, a warehouse is the right instrument.
If your questions are answerable inside individual tools, a warehouse adds a large maintenance surface for insights you’re not resourced to act on. Plenty of organisations have built one, populated it, and never queried it, because the constraint was never data access.
The cheap partial step worth knowing about: GA4’s free BigQuery export gives you raw event data with no sampling and indefinite retention, and it costs nothing to enable. It’s a warehouse foundation you can switch on today and grow into, and it captures data only from the moment you enable it — which makes early enablement the cheapest insurance available regardless of whether you’re ready to use it.
The Governance That Prevents Recurrence Four rules, lightly enforced
Cleaning a stack is a project. Keeping it clean is a habit, and the habit is cheaper.
One person approves new tools. Not a committee, not a procurement process — one named person who asks the two questions from earlier in this article. The point isn’t gatekeeping for its own sake; it’s that someone holds the whole picture and can see that the tool being proposed does what three existing ones already do.
Nothing renews without a review. Put every renewal date in a shared calendar with a reminder thirty days ahead. Auto-renewal is how stacks accumulate, because the decision to keep paying is never actually made — it’s simply never unmade.
Every tool has a named owner and a written purpose. One sentence each. When the owner leaves, the tool goes to review rather than being inherited by default. This single rule prevents more accumulation than any other, because orphaned software is the dominant failure mode.
A quarterly usage check. Most tools report last login. Anything with no activity in ninety days gets a question asked about it. Not automatically cancelled — some things are legitimately seasonal — but questioned.
These four rules take perhaps an hour a quarter to enforce and they hold the line indefinitely. The reason most organisations don’t have them isn’t disagreement; it’s that stack governance belongs to nobody by default, and things belonging to nobody drift.
Dismantling One That Already Happened A ninety-day path
Weeks one and two: inventory honestly. Every subscription, every cost, every renewal date, every owner, every login. Include the ones nobody admits to. Pull the actual figures from finance rather than asking people what they think they spend — the gap is usually instructive.
Weeks three and four: map functions and find overlaps. Which tools do the same job. Which have no owner. Which nobody has logged into in ninety days — most tools can tell you.
Weeks five and six: identify the system of record. Declare it explicitly, in writing, and establish which direction data flows. Every other system reads from it or writes to it, and nothing else is authoritative. This is a decision, not a discovery, and someone has to make it.
Weeks seven to ten: cut. Start with unused tools, which is politically free. Then consolidate the clearest overlaps. Export data before cancelling, always, including from things you’re confident nobody needs.
Weeks eleven and twelve: document what’s left. The integration map, the ownership list, the renewal calendar. Then set a recurring quarterly review, because the accretion resumes the moment nobody is watching.
A realistic expectation: most organisations doing this for the first time remove somewhere between a fifth and a third of their tools without losing any capability, and the larger benefit is usually the data consistency rather than the saved subscription cost.
Integration complexity arithmetic is a simple combinatorial observation rather than a published finding; tool-count ranges reflect the author’s experience rather than industry benchmarks. GA4 BigQuery export behaviour verified against Google’s current documentation. This article contains no affiliate links.