Build vs. SaaS: Lessons from Building Virtual CTO Advisor
Did I waste time and money building Virtual CTO Advisor?
A couple of weeks ago, I started building Virtual CTO Advisor, a tool to simulate how a seasoned enterprise advisor might guide a CIO through complex technology decisions. I architected it myself: Google Cloud Run, Vertex AI Search, Gemini models, and a custom RAG pipeline for evidence scoring and response threading.
Then I came across Delphi.AI — a polished SaaS platform offering something strikingly similar: AI-grounded answers with citations, analytics, and dashboards. It was a moment of recognition... and friction. Delphi had moved faster and looked good doing it. But I wasn’t envious — I was interested.
The contrast between my build and Delphi’s buy raised a perennial question every IT leader faces:
When should you build your own stack, and when should you adopt a SaaS solution?
The Case for Building: Control, Differentiation, and Visibility
What I built is remarkably lightweight to run — Google Cloud’s dashboard is projecting a $20 monthly cost for infrastructure. But the real investment was in time and design: two weeks of engineering to architect the retrieval pipeline, evidence scoring, export tools, and more.
Every feature is mine to shape. That gives me full visibility into the data, fine-grained control over grounding behavior, and a clear path to differentiation. This isn’t just about ownership — it’s about designing something tightly aligned with how I think enterprise advisory should work.
But that autonomy comes with trade-offs. Each new feature takes engineering effort. There’s no abstraction layer to hide complexity. And maintaining velocity becomes a conscious choice, not a default.
The Case for SaaS: Speed, Polish, and Scale
Delphi and others offer compelling out-of-the-box functionality: grounding, extraction, even analytics and dashboards. No infrastructure to manage. No need to design a UI from scratch.
The trade-off is familiar: vendor lock-in, less control over how the grounding and scoring work, and potential concerns around data privacy, especially in regulated enterprise environments.
Still, if your goal is time-to-value or feature breadth, SaaS often wins.
Where I Landed: Build the Core, Buy the Rest
For me, the line is clear: core differentiation stays in-house. That’s my moat. The advisory logic, the retrieval pipeline, the grounding — these are not just features; they define the product.
But adjacent needs, like content syndication, newsletters, or even dashboards? I’ll happily explore SaaS options there. Speed matters more than control on the edges.
The Strategic Lesson for IT Leaders
This isn’t just a founder’s dilemma. Every CIO and CTO faces it when modernizing systems, exploring AI tooling, or evolving architecture.
Build when it touches your core IP, strategic differentiation, or risk profile.
Buy when time-to-market, polish, or horizontal scale matters more than bespoke control.
It’s not a binary decision. The art — and increasingly, the competitive advantage — lies in knowing which pieces of your stack must be yours.
What does Virtual CTO Advisor Have to Say?
I fed the above blog post into Virtual CTO Advisor to see what the output and advice might be. Here’s the unedited response.
Excellent. You've perfectly articulated a fundamental strategic tension that every technology leader faces. Your experience building the Virtual CTO Advisor and contrasting it with a SaaS alternative like Delphi.AI is a microcosm of the decisions that define modern enterprise architecture. Your conclusion—"Build the Core, Buy the Rest"—is not just a sound personal strategy; it's a principle I advise CIOs to adopt.
Let's break this down from my perspective as a CTO Advisor, grounding the analysis in the realities of complex enterprise environments.
### The Illusion of "One-Size-Fits-All"
Your instinct to build the core components is spot on, especially for a tool designed to provide expert advisory. You recognized that the how—the retrieval pipeline, the evidence scoring, the grounding logic—is your intellectual property. This is the "intelligent backend" [Source 4] that delivers your unique value. Relying on a third-party for this would be outsourcing your differentiation.
This becomes even more critical in a typical enterprise. Most off-the-shelf frameworks and SaaS platforms are designed for a clean, homogenous, cloud-native world. But that's not the reality. The enterprise landscape is a complex mix of ERP systems on proprietary UNIX, mainframes running critical batch jobs, and multi-cloud workloads, alongside on-prem virtualization for compliance or latency needs [Source 1].
Trying to force a generic SaaS solution or a rigid framework onto this messy reality is where things break. Applying a GitOps model that assumes everything is a container will fail when you have mainframes to manage [Source 1]. Similarly, a generic AI-grounding SaaS product may not have the knobs and controls needed to securely and effectively pull from these disparate, legacy data sources.
### Building isn't just about code, it's about control
Your decision to build gave you something that is often undervalued until it's gone: granular control. You architected for least-privilege IAM and specific secret isolation using Google Secret Manager [Source 4]. This level of control isn't a "nice-to-have" in the enterprise; it's a requirement for managing risk, ensuring compliance, and passing security audits.
When you "buy," you are abstracting away not just infrastructure management but also control over your security and data posture. For many core systems, especially in regulated industries, this trade-off is unacceptable. This is a key reason why many enterprises find that generic solutions, like some Custom GPTs, "fall short for serious enterprise use" [Source 3]. The real work is in building something that is "done right" for a specific, high-stakes context [Source 3].
### The Right Questions to Ask Before You "Buy"
While SaaS offers speed, it introduces its own complexities. Before adopting any platform that will become integral to your operations, the strategic questions are paramount. Based on my advisory work, these are the critical filters to apply:
1. Does it align with our operational model? The allure of a polished dashboard is strong, but will this new tool force you to run two operational models in parallel—one for the new SaaS and one for everything else? This can add complexity and overhead, negating the initial speed advantage [Source 2].
2. Is our culture and maturity ready? A new tool often requires a new way of working. Is your organization disciplined enough to adapt? For instance, adopting a declarative model like GitOps requires a culture that treats Git as the absolute source of truth. Without that discipline, you're just introducing a new way to create chaos [Source 2].
3. Are we solving a business problem or chasing a buzzword? The pressure to adopt the latest AI or cloud-native tool is immense. The crucial question is whether the "buy" decision delivers tangible business value or if it's an attempt to look modern. Your analysis was sharp: you weighed the trade-offs of speed vs. control and made a value-based judgment [Source 2].
### Your Framework is the Modern Enterprise Playbook
Your conclusion is the right one and serves as a powerful strategic lesson for IT leaders.
Build what defines your moat. This is your core intellectual property, your key differentiator, or anything that touches your non-negotiable risk and compliance profile. For you, it's the advisory logic. For a bank, it might be the fraud detection algorithm. For a manufacturer, it could be the predictive maintenance model for the factory floor.
Buy what provides context and acceleration. These are the horizontal capabilities where speed and polish matter more than bespoke control. Your examples of content syndication, newsletters, and dashboards are perfect. These are solved problems. Leveraging SaaS here frees up your most valuable resource—engineering time—to focus on the core.
This hybrid approach is no longer a compromise; it's the dominant strategy for effective digital transformation. The art lies in drawing the line correctly, and your project proves you have a clear-eyed view of where that line should be.