Last week I watched a junior developer on our team spin up a working CRUD app with auth, database migrations, and a halfway decent UI in about 90 minutes. With Copilot. From scratch.
Five years ago, that same task would have taken a week. Maybe two if you count the yak-shaving around deployment configs and OAuth flows. And that shift, that compression of building time from days to hours, is quietly dismantling one of the oldest questions in software: should we build or should we buy?
The Old Framing is Dead
For decades, "build vs buy" was a cost calculation. You'd estimate how many developer-months it would take to build a thing, multiply by loaded salary, add some buffer for maintenance, and compare it to the annual license fee of whatever SaaS product did roughly the same thing. If the SaaS was cheaper, you bought. If your requirements were weird enough, you built.
That framing assumed building was expensive. And it was. But according to GitHub's Octoverse 2025 data, AI-assisted development now produces a 20 to 30 percent increase in throughput. Eighty percent of new developers on GitHub use Copilot within their first week. Over 1.1 million public repositories already integrate LLM SDKs. Building got dramatically cheaper, almost overnight.
So the question isn't really "build vs buy" anymore. It is something more like: what are you actually paying for when you buy SaaS?
The New Calculus
Here's what I think most SaaS founders (myself included, honestly) don't want to hear: if your entire value proposition is "we saved you from building it," you're in trouble. Because that moat just got a lot shallower.
When a team can prototype a functional internal tool in a day, the bar for what justifies a monthly subscription goes way up. You do not just need to be better than what they could build. You need to be better than what they could build with AI helping them.
Gartner predicted in April 2026 that by 2028, over half of all enterprises will stop paying for assistive intelligence and favor platforms that commit to workflow results. Even more stark: they expect that by 2030, software companies layering bolt-on AI over legacy applications rather than redesigning for agentic execution will face margin compression of up to 80%.
Eighty percent. That is not a rounding error.
So What Actually Survives?
I have been thinking about this a lot, partly because we're building Rasepi and I need to be honest with myself about where our value sits. And I think the answer comes down to three things that are genuinely hard to replicate with a weekend coding sprint, no matter how good your AI assistant is.
Domain depth you can not fake. Anyone can build a text editor. Building a translation system that tracks content changes at the paragraph level, detects stale translations through content hashing, and handles structural adaptation across languages? That takes years of domain knowledge baked into architecture. The AI can help you write the code faster, but it can not tell you what to build.
Someone still has to run and maintain it. Here is the thing about building: it is fun. Maintaining? Not fun at all. Handling edge cases in multi-tenant permission systems, keeping up with browser quirks, managing database migrations across versions, patching CVEs at 2am, dealing with that one PDF export bug that only shows up in Safari. AI makes the initial build faster, sure. But Forrester's April 2026 research shows most enterprises still can not turn AI adoption into measurable impact, partly because the hard part was never writing code. It is keeping the thing running, updated, and working correctly for years. The build is the easy part. It's the uptime, on-call rotations, and incremental fixes that actually cost you.
Trust, security, and data privacy. This one is underrated. When you build something yourself, you own security. You're responsible for encryption at rest, audit logging, penetration testing, GDPR compliance, SOC 2, and the next regulation nobody has heard of yet. A good SaaS vendor has an entire team whose only job is making sure your data does not end up somewhere it should not be. For most companies, that is not a cost they want to carry internally. And honestly, most internal tools I have seen do not even have proper access controls, let alone a security audit trail.
The Composable Middle Ground
What is interesting is that the answer increasingly is not "build" or "buy." It is compose. Pick the SaaS tools that do hard things well, expose good APIs, and let you build around them.
This is why plugin architectures matter so much right now (and yes, this is exactly what we've been investing in with Rasepi's plugin system). The SaaS products that will thrive are the ones that say: "We handle the hard, domain-specific core. You customize everything else." Not "here's our monolith, take it or leave it."
Forrester's April 2026 report found that most enterprises are still struggling to turn AI adoption into measurable business impact. High adopters are 47% more likely to work with consulting partners to prepare their data and systems. The message is clear: raw building capability is not the bottleneck. Knowing what to build, and having the infrastructure to support it, that's the actual constraint.
What This Means for SaaS
If you're running a SaaS company in 2026, I think there are a few uncomfortable truths:
- Your "we'll save you time" pitch is weaker than ever. Time savings was the classic SaaS sell. But when AI compresses build time by 20-30%, the "time saved" number in your ROI spreadsheet shrinks proportionally. You need a different story.
- Features are table stakes, outcomes are the product. Nobody cares that you have 47 integrations. They care that their documentation stays fresh, their translations stay accurate, their team actually uses the tool. Gartner's language about "outcome-focused workflow" is not just analyst jargon. It is where the market is heading.
- Openness beats lockdown. The instinct to close your platform and make switching hard is understandable. But Gartner explicitly warned that "legacy SaaS providers that attempt to close systems of record risk being bypassed by orchestration layers enterprises trust more." Ouch.
The Honest Version
I will be blunt about where I land on this. Build vs buy was never really about the technology. It was always about trust. Do I trust this vendor to understand my problem deeply enough that their solution will be better than what I could cobble together?
In 2026, "cobble together" got a massive upgrade. So the trust bar went up too.
For us at Rasepi, that means we can't just be a documentation tool that happens to support translations. We have to be so deeply good at the hard problems, the block-level translation tracking, the content freshness enforcement, the multi-tenant complexity, that building a replacement would be genuinely painful even with the best AI tools in the world.
That is the new build vs buy. Not "can you build it?" but "should you spend your energy building it when someone else has already solved the hard parts?"
The question was never really about cost. It was about where you want to spend your attention. And in a world where building is cheap, attention is the only scarce resource left.