Navigating the ‘Build vs Buy’ Decision in ResTech

‘Build vs Buy’ in Mr Isn’t a New Question, but the Context Certainly Is

Market Research (MR) has always borrowed from enterprise software, but the pace of this borrowing is now accelerated. Till the early 2000’s, MR was inspired primarily by Enterprise BI features: dashboards, tagging systems, structured metadata. Recently, ChatGPT’s launch made newer conveniences, rapidly available: keyword-based search across transcripts, auto-coding, “ask the dataset” interfaces etc.

Today, MR agencies face pressure to differentiate, the possibility of using AI-assisted coding to build internal tools is indeed tempting. Developers can deliver prototypes faster, which this makes software more affordable.

Yet, before heralding a revolution, it’s worth asking – “What’s the catch here?”.

Code-writing capabilities do not a tool make. Yes, AI can embed new workflows into a tool radically fast. I’ve watched colleagues think, “We live the process, surely we can build the tool!”. Sometimes such optimism works; often not. Post-building, each feature needs security review, integration, monitoring, support, compliance updates and long-term maintenance. So, the build-vs-buy decision in MR is rarely about ‘build’. Instead, it’s about ‘own’: how much operational responsibility your team is willing to carry?

Yes, building is easier today, than it used to be. But, running software for years is not.

MR agencies and their clients have been tempted to become software organizations, since decades. Today, ESOMAR’s industry breakdowns increasingly separate MR services from the ‘Research Software’ sector. Their Global Top Insights Companies 2024 report estimated Research Software’s 2023 turnover at roughly US$56B.

What about MR Makes It Hard to Solve the ‘Build vs Buy’ Dilemma?

MR workflows can be intricate, episodic and exception-heavy. The range of complexity lies within Quant vs Qual, Open-endeds vs Transcripts, Panels vs Customized etc. MR teams often misunderstand familiarity (with MR complexities) as feasibility; and end up overestimating their ability to build sustainable tools. They imagine that because they understand a workflow they can produce software that will consistently run it.

Planning for such a variety of situations means shouldering ongoing responsibilities. These responsibilities aren’t limited to feature-building; and often determine whether the tool survives real projects and real clients. Take for instance:

• Security & access control: role permissions for observers/clients, SSO, expiring links
• Compliance: consent records, retention rules, right-to-delete/DSAR workflows, data residency
• Governance & defensibility: audit trails (who edited transcripts/codes, why summaries changed)
• Integrations: panel/vendor APIs changing, storage, transcription, calendar/scheduling, CRM
• Reliability: monitoring, incident response, uptime, backups, performance during live sessions
• Support & change management: tickets, onboarding, documentation, training
• Edge cases: “this study is weird” requests (new stimuli formats, unusual quotas, permissions, languages)

So let’s try get this right – Building a tool is not the same as writing code. Large IT projects regularly run over  budget and under deliver: research by McKinsey and the University of Oxford on over 5,400 projects found that large IT initiatives run 45% over budget and 7% over time, while delivering 56% less value than predicted.

Even small tools carry hidden costs. Josh Pigford, founder of Baremetrics, put it plainly: “Next thing you know, you’ve spent literally 100s of hours building a tool that’s not core to your business. Hours that really hardly saved you any money. But worse than that, it was hours that weren’t spent making more money by improving your core product”.

Lastly, let’s talk about spiralling buyer expectations. ResTech isn’t a ‘side’ market anymore. Today, the “minimum viable expectation” for MR tools resembles modern SaaS products:

• role-based permissions for clients and observers
• auditability and governance by default
• integrations that don’t break when vendors change APIs
• AI features that accelerate work without breaking defensibility

All in all, MR workflows are being productized. And when you build, you inherit the same expectations that your buyers hold SaaS-vendors to.

Let’s See This Challenge Unfold in the Real MR World…

Here’s the tale of a Frankenstein that outgrew itself…

A mid-sized qualitative agency built an internal “Qual Hub” to solve three pains: scheduling, centralized storage of recordings/stimulus, and need for a simple client portal for sharing highlights. Initially, it was excitedly received by employees and clients alike… Qual researchers stopped hunting across folders, clients loved being handed a single link on a platter, note-taking and archiving became really easy.

Then, reality arrived, one client requirement after another:

• Client1 asked for the data to reside in a particular country.
• Client2 asked for an audit trail of transcript edits and redactions, for a large study they commissioned.
• Client3 had over 10 users, so they needed SSO, granular permissions and automatic expiry for access links.
• Client4’s legal & procurement teams requested incident response plans, and ongoing vulnerability management.
• A recruitment partner changed their API, the day Client5’s fieldwork was scheduled to begin.

This was the cost of becoming “SaaS-like” in a ResTech world. At that point, the agency had to decide : Keep investing and become a software company, or adopt a vendor platform?

Considering the Flipside: Where Building Can Indeed, Make Sense

Around 26% of the ~56B USD ResTech software has been built by research teams themselves, which suggests that some research leaders do make this transition successfully.

Here’s a pragmatic guide that MR teams can use, when evaluating whether to build:

 

Decision driver	Build if…	Buy if…
Differentiation	Your advantage is truly workflow IP	Your advantage is research craft + speed
Variability	Workflow is stable and repeatable	Every study is bespoke and exception-heavy
Governance burden	Low sensitivity / internal-only	Recordings, clients, multi-stakeholder access are the standard expectation
Integrations	Few, stable API dependencies	Many vendors, panel partners, shifting APIs
Time horizon	Multi-year commitment with ownership	Need value this quarter; can’t staff ownership of tool(s)
Risk tolerance	You can absorb outages + learning	Client-facing reliability is non-negotiable

The key is to be honest about what you won’t do: you won’t…

1. build a platform for every use case
2. support a long list of integrations
3. expect others to adopt your tool.

Success comes when teams accept the limits and plan for longterm tool-ownership.

Admittedly, author-bias creeps in here. I build qualitative research software for living, so my instinct is to lean toward Buying. Even from that seat, I’ve seen internal tools succeed only when they are intentionally scoped and when organizations assign clear ownership and resources for maintenance. What fails is the fantasy that a single project will blossom into a platform or that clients will clamor for what you built as restricted-use solution.

It’s Time We Reframe the Question

So, we’ve established that the buildversusbuy debate is rarely about code or features. It’s about focus, commitment and tradeoffs. Building internal tools can indeed be a path to differentiation and control, if organizations acknowledge the structural and human costs.

Yes, generative tools can shorten the time from idea to prototype. But they don’t relieve teams of ongoing tool-ownership and maintenance, which grow as code volume, dependencies, and stakeholder expectations compound.

The pressure to choose between build vs buy will only grow, as AI continues to productize MR workflows. A more useful question to pursue then, is: How much responsibility does Insights teams really want to take on? If your advantage is research craft and speed, Buying protects focus. If your advantage is workflow IP, and you’re prepared to staff tool-ownership like a SaaS team would; then Building works better. For many teams today, the most resilient answer is hybrid: buy the platform layer that handles governance and reliability, and build narrowly where you truly differentiate.