This shift is powered by tools like Lovable, Replit, Figma Make, Claude Code, and Codex, which now enable non-engineers to prototype, build, and ship real software. With these platforms, the cost of experimentation has dropped to nearly zero, which fundamentally changes the build-vs.-buy equation more than most systems teams have fully reckoned with.
The question used to be: Is it worth building this ourselves? The answer was almost always no—too expensive, too slow, too hard to maintain. The question now is: Who owns what gets built, and what happens after it ships?
That ownership question is what RevOps leaders need to be thinking about right now.
The Shift is Already Happening
At Go Nimbly, one of the clearest examples is a quoting and estimating app built internally using Lovable. Instead of implementing a full CPQ, we needed something tailored: an internal interface for building estimates and a client-facing view for presenting quotes. One of our engagement managers with a background in solution design and marketing owned it from ideation through deployment, and the team quickly adopted it. People are genuinely enjoying building tools for their colleagues.
In some ways, this is what Salesforce always promised: a flexible platform where any business process could be configured and run. But Salesforce is heavyweight. Point-and-click development, sandbox-to-production migrations, change management, integrations—it all adds up. Vibe coding lets teams skip a lot of that overhead and build exactly what they need.
The math is changing in ways that deserve serious attention. Building custom software used to make little sense for a systems team, but that’s no longer true. Not just because the tools are cheaper, but because the interface has finally become intuitive enough for someone without an engineering background to own a software project end to end.
The Product Mindset
The tools are only half the story. The more important shift is what happens to ownership when building becomes accessible.
When someone on a systems team can own a tool from initial idea through deployment, and iterate on it based on user feedback, that’s a product mindset. It's a fundamentally different view of what RevOps does: not just implementing and configuring tools built by others, but building and maintaining tools of its own.
At Go Nimbly, R&D is currently distributed. People across the company are passionate about different problems—customer health scoring, PMO standardization, quoting logic, LLM experimentation—and take ownership of those areas. This model is both a gift and a challenge, and it only works because the cost of building has dropped far enough to make it viable.
The questions systems teams should be asking are: Are we set up to support this kind of ownership? Do our people have the latitude to build, iterate, and maintain? Or are we still organized around a model where building is someone else's job?
The Real Costs Haven't Disappeared
Here’s where a dose of realism is necessary.
Traditionally, 90% of software costs are in maintenance, not the initial build, and that hasn't fully changed. There’s still a human in the loop, guiding agents, handling edge cases, responding to end-user feedback, and making judgment calls when something breaks. The cost might shift, with some of it going to agents instead of engineers, but maintenance is real and it accrues to whoever owns the system.
There's also a subtler risk: the tendency to rubber-stamp whatever an AI coding tool suggests. People might say "yeah, go for it" without fully understanding the change, or see an error in a terminal and point the model at it without actually reading it. This is a human pattern, and likely a systemic one for non-engineers building with these tools, not just an individual quirk.
A software-checking-your-software layer, something that validates quality, flags security issues, and checks for problematic dependencies, is already emerging as a practice and will likely become standard. Troubleshooting is also worth watching. Pointing a model at a screenshot of an error works well for simple apps, but how that holds up as infrastructure grows more complex is a genuine open question.
Shadow Infrastructure is the Governance Problem Nobody's Talking About
There's definitely a version of this future that looks chaotic, and it's already starting.
When someone says they built a "Gemini gem" for a workflow, a reasonable follow-up is: where does it live? Does IT know it exists? What happens when that person leaves? As vibe coding scales, organizations will end up with code, configuration, and logic scattered across Lovable projects, AI platforms, hosted apps, and personal accounts. Source control and GitHub exist for a reason, and that reason doesn't go away just because building has become easier.
The IP question is genuinely interesting here. Increasingly, the value lies in how a problem is framed and solved—the prompt architecture, workflow design, and judgment calls baked into the logic—rather than the specific code that gets generated. But company leaders still need visibility into the infrastructure their business relies on. If a critical quoting tool lives in someone’s personal Lovable account with no version history or documentation, that’s a liability, even if the tool itself works perfectly.
Organizations that approach this thoughtfully will establish lightweight governance early: where tools live, who formally owns them, and what the offboarding process looks like when someone leaves. This doesn’t require a heavy-handed IT policy. It requires deciding that shadow infrastructure is a risk worth managing.
The Opportunity is Real, but Ownership is the Work
The barrier to entry for experimentation has never been lower, and there's no excuse for teams to not be experimenting right now.
But the teams that actually extract lasting value from vibe coding won't just be the ones that build the most things. They'll be the ones that clearly define ownership, know how to maintain their tools, and ensure the organization’s infrastructure remains visible and governable as it becomes more distributed.
