There are two ways to assemble a powerful martech stack: buy or build it. For some of us MOps folks, “build vs. buy” is a frequent debate—a difficult choice between spending a limited budget or building and maintaining an internal solution. And even more teams choose to buy even when it’s expensive, because they don’t have a way to build a solution quickly and effectively themselves (i.e. they don’t have an iPaaS).
I’m in a fortunate position where I don’t need to buy everything. I have the Workato iPaaS in my stack and can balance out the necessary martech “buys” with plenty of integration and automation “builds.” This approach saves money, yes—but the real beauty is in the possibilities for innovation it opens up. Builders have the power to fill in the gaps where point solutions don’t even exist on the market.
Most MOps folks don’t know how much they can actually build. I think that can and should change. To provide a blueprint, I thought I’d give you a glimpse into the Workato martech stack, as well as my thought process when evaluating new software and the “build vs. buy” decision tree I use when deciding what to build.
Meet your martech stack
The martech stack comprises many different applications, i.e. coded platforms that let the user perform tasks, generate insights, and facilitate business processes. These processes include key marketing activities like outbound, account based marketing, paid advertising, events, and pipeline prediction.
If you inventory all your marketing applications, your martech stack might look something like Workato’s current stack, below. (Check out Scott Brinker’s Stackie Awards for other examples of real stacks.)
How to grow the martech stack sustainably
Large martech stacks put powerful applications at marketers fingertips, but the sheer number of solutions available means these stacks can get out of hand when MOps teams buy much more than they build. Furthermore, there are often gaps between solutions that native applications or external solutions can’t solve for. That’s why I think it’s important to balance the temptation to buy with a build mentality whenever possible.
Most MOps folks aren’t developers, but you don’t need to know how to code to build your own solutions. At Workato, we integrate and automate using our own low code/no code platform. The team builds in Workato every day and maintains a portfolio of 3K+ internal automations. For example, we have Slackbots that route leads, Google forms that create Marketo programs, and automated buyer journey maps.
If you don’t have an iPaaS like Workato, building means making the most of native integrations, manually importing/exporting data between systems, or working with BT or IT to develop custom integrations. There are challenges to building this way, like slow delivery, data silos, and coding errors, but some MOps teams go that route. I personally wouldn’t recommend it.
How to evaluate vendors with a build mindset
Let’s say you are evaluating a new application. Building a solution internally can be incredibly advantageous, especially when the software tool is not mature and lacks native integrations.
Why buy a tool that solves one issue but creates another? This is the paradigm we face in buying B2B SaaS tech in the modern age. Every business has a different tech stack, and with that requires custom or different solutions.
You might also debate “build vs. buy” while in the process of renewing your current stack. For example, if native integrations cost money—you could build them instead. If a vendor wants to upcharge you for their new AI copilot—you could integrate the application with your existing AI to create your own copilot.
It isn’t just about bargaining chips and saving money though. It’s more about pushing the limits of what’s possible with your current stack and finding new ways to get value out of what you already have.
Is it a core application?
Applications in the martech stack are more or less integral. Some are part of the core stack that keeps the lights on across the marketing department, while others are point solutions designed to address a particular problem or a narrow set of issues within an organization. Unlike core applications that tackle multiple problems or offer a wide range of functionalities, point solutions are targeted and specialized.
As you evaluate applications, it may be helpful to think about them as either:
- Core applications that orchestrate multiple marketing functions
- Point solutions that perform specific, limited actions
You can find a few core application types in virtually every martech stack. I believe you should buy (not build) these applications, to form a strong foundation for the rest of your stack:
- A CRM platform, like Salesforce
- An MAP, like Marketo
- A sales enablement platform, like Outreach.io
- An AI, like OpenAI
- An iPaaS, like Workato (my opinion)
If, on the other hand, you’re looking at a point solution, you’re stuck with a difficult buying decision: purchase an overpowered tool or purchase a tool with extremely limited capabilities and no scalability.
I’ve dodged this pitfall many times by building point solutions instead of buying them. And it’s not just me—in conversations with Workato customers I’ve noticed that, with the combination of a solid core stack and Workato, MOps teams can build almost any point solution using integration and automation.
Here are a couple of examples of what we have built internally with Workato:
- Lead routing
- A campaign launcher
- Automated content delivery
Does it have a native integration?
You may have noticed that I’m a huge proponent of an integrated martech stack. Your integrations are just as important as your core applications (of which an iPaaS is one), as they keep your entire stack working together seamlessly, building on each other to create marketing synergy.
Most modern platforms have some native integrations or open APIs, but it’s not uncommon for these tools to still lack the functionality and scalability you need to perform a specific process. Take Google Adwords, for example. Its native Salesforce integration includes the Contact and Account objects, but not the Lead object. If your business operates on a lead, contact, and account object, what do you do in this scenario? Do you continue with an integration that is incapable of connecting to the lead object?
I leverage Workato to fill in these gaps. If I end up with a tool that has an integration gap in my stack, like Adwords, 99% of the time I can build a point solution for it in Workato. The advantage of building this internally is I have a lot more flexibility and can fit this in with our native systems and processes.
Is it a data tool? Is the data proprietary?
If an application comes with external enrichment or intent data, you may need to buy it. In my experience, it’s typically not worth building these data depositories. For example, I might choose to buy:
- An enrichment platform, like ZoomInfo
- An intent tracking platform, like Demandbase
A platform powered by your data, on the other hand, is a good opportunity to build. it’s more desirable to build a point solution that facilitates business processes by data and actions, not by system. It also benefits security to handle sensitive data internally, instead of processing it through a vendor.
You can also extract the full potential from external data tools by leveraging Workato to connect them in a composable system. I consider a tool like Demandbase a core application, but by leveraging our APIs and the power of data from their tool, we are able to get more value out of it. For example:
- Demandbase tells me when a target account visits my website, information I do not get today unless they are known or if I have reverse IP
- Using Workato, we take that data, and leverage ZoomInfo to find our key ICP
- Then we take those that ICP and filter them out in Salesforce to make sure they have not been touched before
- We then call OpenAI and have a personalized email generated
- Lastly, we route and sequence them on behalf of SDRs in Outreach
Is the user interface a key value driver?
If you’re evaluating a tool where less technical marketing teams will hold most of the seats, the user interface can make or break your build vs. buy decision. It might be worth it if you feel like the UI will have a huge, positive impact on the application’s adoption rate, user experience, and productivity.
For example, I choose to buy:
- Design platforms, like Knak
- Analytics platforms, like Sigma
Here are a couple applications you could build, as the UI is less important:
- Approval platforms
- Gifting platforms
Is it impossible or inefficient to build?
As you do your due diligence during evaluation, take note of the workflows behind the application’s processes. Once you understand the application’s workflows, decide whether or not you can build it.
The answer will depend on two factors: the complexity of the application’s workflows (which is outside your control) and the strength of your integration skills and capabilities (which is within your control). If you’re working with native integrations, you may be constrained. With an iPaaS, more is possible.
The build vs. buy decision tree
This simplified decision tree can help you decide whether to buy a solution or build it yourself. It visualizes a thought process I’ve developed over time, and used to evaluate hundreds of vendors. While I’ve purchased some of those applications, I’ve built even more.
Preface with evaluating pricing and time to build. iPaaS is a dependency. If you’re a customer, this will make sense. If not, here’s a way to think about it in the future when you are a customer.
The build mindset
The most important advantage to balancing buying applications with building integrations and automations is innovation. A build mindset supports both a state-of-the-art stack and a creative team. I want new technology to fit snugly into the stack and don’t like buying tools that introduce gaps or missing areas which require additional solutions anyway. And, as a MOps leader, I don’t want to limit what my team does from an innovation standpoint by buying applications with redundant or limited capabilities.
An iPaaS fills in the gaps in the martech stack with enterprise automation and integration rather than buying point-to-point solutions. Furthermore, this promotes scalability, customizability, and speed to drive growth and operational efficiency—so folks can pioneer processes outside the limits of existing platforms.
At Workato, the MOps team is lucky enough to have our own tool to enable us. We have the option to stray away from textbook solutions and take an active role in engineering our own martech stack. You don’t have to work at an iPaaS company to have a build mindset though. Any MOps team can integrate and automate with an iPaaS, and push the limits of what’s possible with your martech stack.
