Everyone Is a Builder Now. That's a Good Thing.

The SaaS companies that thrive next are the ones worth building on.

By Ori Entis, EVP & GM of Product and Engineering at Gainsight

For years, SaaS worked on a simple premise. We build the platform. You configure it. Everyone stays in their lane. The vendor’s job was to ship features fast enough that customers never seriously considered an alternative.

That premise is gone. With agentic coding tools, anyone with an engineering team, and increasingly anyone without one, can build functional software quickly. Your customers know this. They’re thinking about it. Some of them are already doing it.

According to Retool’s 2026 Build vs. Buy Report, 35% of enterprise teams have already replaced at least one SaaS product with custom-built software. 78% plan to build more this year. This shift is happening in real time.

The instinct is to treat that as a threat. I don’t think it is. I think it’s the most interesting thing that’s happened to SaaS in a decade.

The Question We Asked Ourselves at Gainsight

Earlier this year I flew to India and challenged the Gainsight CS product and engineering team with a question that I’d been circling around for a while. Our customers were increasingly becoming builders and our users are no longer people, but agents as well. They had engineering teams, agentic coding tools, and a growing willingness to route around software that wasn’t moving fast enough for them. Were we going to build for that reality, or pretend it wasn’t happening?

We’ve since released Gainsight’s MCP connector for our CS and Staircase products, with more more on the roadmap.

This decision was a genuine reckoning with what customers expect from a platform in 2026. Customers are no longer bound to our UI and instead have a foundation to build on.

I said something similar in a memo I sent to my product and engineering org around the same time. The short version is that we’re no longer just competing with other vendors. We’re competing with our customers’ own ability to build. When a customer asks for a feature or a bug fix, they don’t only compare us to another vendor anymore. They compare us to what their own team could spin up in a week. One workaround, then another, then another, and value quietly migrates out of your platform.

The response I called for internally was to get faster. Feature requests delivered in days, not months. A Forward Deployed Engineer motion that ships customer-specific solutions quickly and pulls the best back into the core product. Stop acting like customers have nowhere else to go, because they do now.

The team was 100% onboard and we started to redesign our Software Development Lifecycle (SDLC) to support this agentic coding that will deliver the required speed and flexibility. Utilising Theory of Constraints (TOC), we reviewed stage after stage in the pipeline identifying bottle necks and solutions with a goal of speeding up the throughput overall and not a single stage like coding.

But rereading it, the deeper point isn’t velocity. The customers building around us aren’t the problem. The problem is that they feel the reason to build in the first place. Speed and openness are the answer, not because they protect the moat, but because they make the foundation worth building on.

The New Model Is Build and Buy

The future isn’t 100% Gainsight or 0% Gainsight. It’s probably 80% Gainsight, the core workflows, the data model, the institutional knowledge accumulated across thousands of implementations, and 20% something the customer built specifically for how they work.

Enterprise software is complex, supporting many edge cases, security, permissioning, scale, stability and of course workflows and features that have been built over years codifying our expertise in our space.

That 20% isn’t a failure. It’s a sign of a healthy, embedded relationship. A customer who is building on your foundation isn’t building around you. They’re extending you. That’s stickiness, not risk.

What This Shift Looks Like in Practice

The shift from “we build it” to “we are the foundation” demands two things that are genuinely hard, and I want to be honest about that.

The first is depth of knowledge. The foundation that our customers trust is our expertise in the domain. Features, workflows, data analysis that are unique to our domain and are coded into our products over years of experience. The coding is not the hard part, the understanding of the problem and the product capabilities that help customers solve them are a reason customers will use your solution.

The second is openness. MCP, APIs, extensibility by design. If customers can’t build on you, they’ll build instead of you. Elena Verna wrote something on this recently: if your product isn’t exposed through MCP, agents can’t use it, and if agents can’t use it, you’re not part of the workflow anymore. The uncomfortable truth here is that our UI is not a moat. Ease of use is not a moat. What survives is whatever can’t be replicated at the output layer. Those are completely different outcomes, and the distance between them is mostly a product philosophy decision made years before the customer ever considers building anything.

Example of Renewal Preparation Brief using Gainsight MCP in Claude

We used to think of SaaS as a product you sell. I think of it now as a platform you offer. And for CS leaders specifically, it reframes the conversation you should be having at every QBR. Not just “are you getting value from the product,” but “are you building on us in a way that makes us harder to leave.”

The vendors who thrive in this environment won’t be the ones who build the most. They’ll be the ones who make their foundation so good, so open, and so fast-moving that building on them is always a better answer than building around them.

That’s the bet we’re making.

---

Ori Entis is EVP & GM of Product and Engineering at Gainsight, leading product and engineering for Gainsight CS and Staircase AI. He’s the founder of Staircase AI acquired by Gainsight in 2024.