MarTech Stack: What to Buy First, and What to Skip

The build order — and the layer almost everyone buys too early.

What a martech stack is, layer by layer

A martech stack is the set of tools your marketing runs on, and the connections between them. The connections are the stack. The logos are just parts.

Which is why a diagram of six vendor boxes tells you little: one vendor can sit in two layers, and two tools in one category often do different jobs.

So define each layer by the job it does. Automation is one job inside one layer, and our guide to what marketing automation is and when it is worth setting up covers it on its own, so this page stays on the architecture around it.

Four layers, plus the wiring:

• Capture — forms, chat, landing pages, call tracking. Anything that turns an anonymous visit into a named person who agreed to hear from you.
• Store — the one place holding the customer record: identity, source, stage, consent, history. A CRM for most teams; a customer data platform once several sources argue about who someone is.
• Activate — email, sequences, automation, ad platforms, personalisation. Everything that sends or shows something to a specific person.
• Measure — analytics, attribution, dashboards. The layer that tells you which of the above worked.
• Connective tissue — tag management, a data layer, and the integrations moving records between the four. Nobody budgets for this and it decides everything.

The build order most teams get wrong

Here is the real finding. Almost nobody buys these layers in the order that makes them work: the usual order is activate, then measure, then capture, with store bolted on late and the wiring never.

That is why so much automation sends the wrong thing to the wrong list. A stale or duplicated record does not fail loudly — it quietly sends a welcome email to a customer of two years.

Build it in this order instead.

1. Capture, first and cheaply. One form standard, one chat route, one way to log a phone enquiry — so nothing arrives unseen. Gives you: a complete inbound list.
2. Store, before anything that sends. Pick the system that will hold the customer record and make it the only one that does. Gives you: a reliable customer record — one row per human, with source and stage. Our guide to choosing a CRM for a small business is where that choice belongs.
3. Measure, before you spend to scale. Analytics and conversion tracking wired to real events. Gives you: a way to tell a good channel from a lucky month; our marketing analytics guide owns this layer.
4. Activate, now there is something to act on. Email and sequences first, because they use the record you just made trustworthy; ad audiences next. Gives you: segmented sending instead of broadcast.
5. Connective tissue, continuously. Tag management from day one, integrations reviewed whenever a tool joins. Gives you: all of the above still true next year.

Skip a step and you do not get a smaller stack. You get the same stack plus someone's afternoon spent reconciling it.

What each layer needs before it is worth buying

Use it as a purchase gate. If the third column is not true yet, the tool gets bought, half-adopted and renewed anyway.

The minimum viable stack for a five-person marketing team

A five-person team needs six capabilities, not sixteen tools. Several of these usually come bundled, which is the point.

• Pages you can publish without a developer.
• Forms and one enquiry route writing into the customer record.
• A CRM that is genuinely the single source of truth.
• Email and sequences, reading segments from that CRM, not an uploaded sheet.
• Analytics and a tag manager, conversions defined once.
• One reporting view the whole team looks at.

What a five-person team is allowed to skip: a customer data platform, a dedicated attribution tool, personalisation engines, product analytics, a warehouse, and anything sold as a suite. Each solves a problem of scale you do not have yet.

This page quotes no prices on purpose. What matters at this size is the billing model — per contact stored, per email sent, per user per month, per seat, per task or per event — because it decides whether a tool gets dearer as you succeed or as you stall. Our breakdown of marketing automation tools by category and pricing model is where that comparison lives.

What a fifty-person team adds

Bigger teams do not buy better versions of the same tools. They add capabilities that exist only once several teams write to the same data.

• Identity resolution — stitching the same person across web, app, offline and support. Where a customer data platform earns its place.
• A warehouse as the reporting source, so no dashboard depends on one tool's export.
• Multi-touch attribution, because with eight channels running, last click stops being a tie-breaker.
• Governance — naming conventions, a tracking plan, access control, and someone who owns the wiring as a job, not a favour.
• Cross-channel orchestration, so one suppression decision applies everywhere at once.

Four of those five are about data and ownership, not sending. That is what a stack grown in the right order looks like.

Integration is the decision, not the feature list

Two tools that do not talk produce manual exports. Manual exports produce stale data, and stale data produces someone's afternoon.

So run one test before buying anything, at any size: can this tool read from and write to the system that holds your customer record, on its own, both ways?

• Native, two-way sync. Reads segments live, writes activity back — opens, replies, stage changes. This is the yes.
• One-way, or through a connector. Workable, billed per task or per operation, and it adds something that can silently stop. Fine for a minor field.
• CSV import and export. That is not an integration. That is a recurring meeting.

Ask the specific version too: which fields, which direction, how often, and what happens to a record that already exists. "We integrate with your CRM" has meant a nightly push of email addresses, one way.

Tag management and the data layer, briefly

Tag management is how tracking gets deployed and changed without a developer release. A data layer is the structured object your site writes into so tags can read it consistently.

Google defines the data layer as "an object used by Google Tag Manager and gtag.js to pass information to tags", with triggers configured against the variables and events it carries (Google Tag Manager developer docs, last updated 22 July 2026). The site publishes facts; the container decides what to do.

Why it belongs here: a data layer stops every new tool needing its own tracking work. Build it once and the next three tools are a container change, not a sprint. Our Google Tag Manager guide covers containers and triggers; the conversion tracking guide covers which events are worth firing.

How to audit the stack you already have

Most stack problems are not missing tools. They are tools you already pay for that nobody opened. A martech audit is a one-sheet inventory — an afternoon, not a project.

List every tool with marketing in it, including ones sales and support bought, and record six things against each.

No logins and no owner is a cancellation conversation; an owner but no integration is the next thing to wire, not replace. If a tool feeds no number in the marketing KPI set you report on, it is hard to call it part of the stack.

Consent and first-party data as a design constraint

Consent is not a chore bolted on at the end. It shapes which layer holds what, and it is far easier to design for than to retrofit.

Two things follow. Consent is collected at the point of capture and stored on the record, in the store layer, so activation can read it. And tracking behaves differently depending on what was granted.

Tag management enforces that last part. Google Tag Manager has consent settings in which tags with built-in checks change behaviour according to what has been granted, plus a Consent Initialization trigger that fires before other triggers so those settings are honoured first (Google Tag Manager Help — this page shows no last-updated date; read 7 October 2026).

The consequence: a stack built on data you collected yourself, with permission, degrades less when a platform signal changes. That is the case for treating the store layer as the asset, which our first-party data guide takes further. This is architecture, not legal advice — get the specifics for your market from someone qualified.

What we find in client stacks

Digital Hangover's own observation, from client work. A pattern we see repeatedly in audits, not a measured study. It carries no figure and we will not invent one.

The question that reveals a stack problem fastest is this: where does a lead live five minutes after it is submitted, and who put it there?

If the answer involves a person — a download, a paste, a forwarded sheet, a nightly check — you have found the break. It is almost never the tool anyone complains about.

The commonest thing we find a client paying for and not using is the automation tier of a system they already own — usually a CRM upgraded for exactly that reason — while campaigns still go out from a separate email tool with a hand-uploaded list. Dormant seats for people who have left are a close second. Both surface in that one afternoon of inventory, which is why we start there.

Where to go from here

Do the inventory first: you will usually find the next three months of stack work already paid for. Then fix the order, not the logos — make one system the customer record, point every capture point at it, define your conversions once, and only then look at what you want to send.

A stack built this way stays small for longer, and the small version is the one people actually use.