Choosing a B2B martech stack: what to buy, what to skip, what to build

Fix the data model before you buy anything. Most B2B stacks fail at the layer nobody demos, which is the agreed definition of a lead and the place your history lives. Buy the CRM and the automation platform, be sceptical of anything promising to sit on top and tell you the truth, and build only the thin layer that encodes how your business actually defines things.

What are the layers of a B2B martech stack?

Six, and they are worth separating because they fail differently.

System of record. The CRM. Accounts, contacts, opportunities, the pipeline everybody argues about. Whatever else changes, this is the thing the business trusts, and every other layer is eventually judged against it.

Marketing automation. Email, forms, nurture, scoring, campaign membership. The layer with the most features you will never use and the pricing model most likely to surprise you in year two.

Data model. Where records from every source resolve to one person and one company, and where your agreed definitions are applied. The layer nobody demos, because it is not a product. It is a decision followed by some engineering.

Analytics and measurement. Site behaviour, media performance, attribution. This layer is where the ownership question bites hardest, and it is covered further down.

Enrichment and intent. Firmographic data, technographics, buying signals, third party intent feeds. Useful when applied to a target account list. Expensive noise when bought before one exists.

Content and web. CMS, landing pages, forms, personalisation. The layer most likely to be chosen for reasons that have nothing to do with marketing.

Most stacks we audit contain more systems than anyone in the business can list from memory, and at least one that a single person maintains by hand and has never mentioned.

Which layer should you fix first?

The data model, almost every time.

The argument is simple. Every other layer produces output that gets graded by the data model, so if that layer is absent, each tool arrives carrying its own default definition of a lead and you end up with five definitions and no way to reconcile them. You can change vendors in any other layer and lose relatively little. You cannot recover history you never modelled.

There is also a sequencing point that saves real money. The definitions work costs you meetings, not licences. Getting marketing, sales and finance to write down what a lead is, what makes it qualified, what counts as an opportunity and who decides, is free, contested, and the single highest return week in the whole programme. Most teams do it after the purchase, at which point the tool has already made the decision for them.

Fix the data model first and the rest of the stack becomes a set of replaceable parts. Fix it last and every platform you own has quietly encoded a different answer to the same question.

What should you ask a vendor that they would rather you did not?

The demo is designed to answer the questions everybody asks. These are the ones that tell you what year three of the contract feels like.

If we leave, what exactly do we get back, in what format, and how long does the export take? Ask for the answer in writing. A vendor confident in its retention rate answers this in a sentence.

Which of the features in this demo have shipped, and which are on the roadmap? Ask it whilst the demo is running, about the specific screen in front of you.

Show me the pricing at three times our current contact volume. Contact tier creep is the most common reason a martech budget doubles without anybody deciding it should.

Who does the implementation, you or a partner, and at what day rate? The licence quote and the go live cost are frequently different orders of magnitude.

Show me a reference customer at our size, in our sector, live for two years. Not the flagship logo. Someone with your headcount and your mess.

What are the API rate limits, and what does raising them cost? This decides whether your data model can actually be fed.

What proportion of your customers renewed at the same tier or higher last year? Most will decline. The decline is informative.

When our CRM changes its schema, what breaks and who fixes it? Every long running stack has to answer this eventually, usually at a bad moment.

You are not trying to catch anybody out. You are trying to find out what this looks like when the person who bought it has left and the integration has been running unattended for eighteen months.

What does it actually cost beyond the licence?

The licence is the part you can see. On a marketing automation platform, our working assumption is that it accounts for somewhere between a third and a half of the real first year cost.

The rest sits in six places. Implementation and configuration, whether done by the vendor, a partner or your own team at the expense of something else. Migration and data cleanup, which is always worse than the audit suggested. The internal administrator, usually an unplanned half of somebody's role that quietly becomes permanent. Integration maintenance, because connectors break when either end updates. Training, and then training again when the person who knew the platform leaves. And tier creep, as contact volumes, send volumes and seat counts drift past the thresholds in your contract.

Then there is the cost nobody puts in the business case, which is the exit. If your measurement history lives inside the platform, leaving costs you the history. That is not a line item. It is a negotiating position, and it belongs to the vendor.

Where does the build versus buy line sit?

Buy the commodity. Build the thin layer that carries your definitions.

Never build a CRM, an email sending platform, a CMS or a consent manager. These are solved, the market is competitive, the compliance surface is large, and anything you write will be worse and will need maintaining by someone who has since moved on.

Do build, or at least own outright, four things: the logic that turns raw records into your definition of a qualified lead, the reporting model that produces the numbers your board sees, the mapping between CRM fields and that model, and the register of what you have tested and what it produced. Each of those encodes a decision your business made. No vendor default matches it, and configuring their default to approximate it leaves you with a business rule living inside somebody else's product.

There is a middle option most teams skip past. Configure heavily rather than build. A surprising share of what people expect from custom development is available through careful field design, naming conventions, lifecycle stages and workflow inside tools already being paid for. Before you scope a build, get someone who genuinely knows the platform to tell you what it can already do. It is almost always more than the person currently administering it believes.

Why does it matter who owns the measurement layer?

Because your switching cost includes your history, and the vendor knows the exact size of it.

On the HMS Networks programme, measurement for work running across seven markets sits on infrastructure HMS owns, using Matomo alongside the CRM, rather than inside the platforms buying the media. On a stack diagram that looks like an implementation detail. Commercially it is the most consequential choice on the page.

Three things follow. The reporting is not produced by the platform being assessed, so nothing is grading its own homework. The record survives a supplier change, which means two years of history stays yours when a channel is dropped. And at renewal you are negotiating about a tool rather than about your own past.

It also makes the localisation work legible. The programme runs across seven markets, with the German engineer searching PROFINET and the American searching EtherNet/IP each finding something written for them, and the same model measuring both. The outcome was 35:1 on media, with cost per qualified lead falling from around £760 through trade events to around £72. Those numbers are only quotable because one model, owned by the client, defined what was being counted.

The same principle applies to your test register. If the log of what you have tried and what it produced lives in an agency's tool or a platform's reporting module, it is not an asset you hold. Kill Perfect, the testing system I set out at Webflow Conf in Boston on 2 September, runs on exactly that assumption: the register is the compounding part, so it lives with the client.

What should you skip?

Six purchases that consistently disappoint when made too early.

Anything promising attribution truth without touching your CRM. A customer data platform bought before the definitions exist, which produces a well engineered version of the disagreement you already had. Intent data bought before there is a target account list to apply it to. Personalisation bought whilst your form data is still unreliable. A second analytics platform purchased to check the first one, which gives you an argument rather than an answer. And sales engagement tooling bought by marketing without the sales director in the room, which nobody adopts.

None of these are bad products. They are all fine at the point in the sequence where they belong.

Where to start

Three things this quarter, none of which cost anything.

Build the grid. Every system holding customer or campaign data, its owner, what it is authoritative for, what it costs including internal time, and what breaks if it goes away. Most teams cannot complete it on the first attempt, and the gaps are your audit.

Put the lead definition from your CRM next to the lead definition in your marketing automation platform, side by side, in writing. If they differ, you have found why your reporting disagrees with itself and it cost you an afternoon.

Before your next renewal, ask the export question in writing and file the answer. You will need it either at the negotiation or at the exit, and asking early costs nothing.

Our martech stack strategy work starts with that grid, marketing technology covers the selection and the business case, and martech integration and configuration is the build itself, on infrastructure you own.

Frequently asked questions

What should a B2B martech stack contain? Six layers: a CRM as system of record, marketing automation, a data model where records resolve and definitions are applied, analytics and measurement, enrichment and intent data, and the content and web layer. Most businesses buy the first two and the last one, then discover the missing data model is why the reporting never reconciles.

Which part of a martech stack should you fix first? The data model, almost always. Every other layer produces output that gets graded against it, so without one, each tool applies its own default definition of a lead and you end up reconciling five answers. The definitions work costs meetings rather than licences, which makes it the highest return week in the programme.

How do you evaluate a marketing automation platform? Ask what the demo is not designed to answer. What you get back if you leave, in what format and how long the export takes. Which features have shipped versus which are roadmap. Pricing at three times your current contact volume. Who implements it and at what day rate. And a reference customer at your size, in your sector, live for two years.

What is the true cost of martech beyond the licence? Implementation, data migration and cleanup, an internal administrator who is usually an unplanned part of someone's role, integration maintenance, training and retraining after turnover, and tier creep as volumes drift past contract thresholds. On a marketing automation platform, our working assumption is that the licence is between a third and a half of real first year cost.

Should you build or buy marketing technology? Buy the commodity: CRM, email sending, CMS, consent management. Own the thin layer that carries your decisions: your qualified lead logic, your reporting model, the mapping between CRM fields and that model, and your test register. Before scoping any build, check what heavy configuration of the tools you already pay for can do, which is usually more than the current administrator thinks.