How Coding Agents Killed Our SaaS Dependencies

Chris Bartholomew•
How Coding Agents Killed Our SaaS Dependencies

When we started building Hindsight Cloud—the cloud service for our state-of-the-art open-source agent memory system—I wanted to fully leverage modern AI coding capabilities.

Based on what I saw was possible with Claude Code and similar tools, I had two core principles:

  1. A monorepo so the agent can see everything—from the core OSS repo (as a submodule) to the deployment code (Terraform), integrations, and self-managed open-source projects.
  2. Minimal dependencies on external services. This meant either self-hosting open source (Postgres, Zitadel) or replicating the functionality in our own codebase.

As the cost of writing and maintaining code approaches zero—and DevOps in Kubernetes trends in the same direction—it makes sense to write the code you want and self-host anything larger than a breadbox (database, auth). Give the coding agent the full picture and let it figure things out.

We have an existing RAG pipeline cloud service built before the era of smart coding agents. At the time, we relied on several external SaaS services to get to market faster. Today, Hindsight Cloud is functionally equivalent to our RAG cloud service, but we no longer use the following SaaS tools:

  • Cognito for auth (replaced with self-hosted Zitadel and our own code)
  • DynamoDB for configuration storage (replaced by the Postgres instance we already self-host)
  • AWS Timestream for usage tracking (replaced with the TimescaleDB extension on Postgres)
  • LaunchDarkly for feature flags (rebuilt in-house)
  • A billing system for subscription invoicing (rebuilt in-house)
  • A billing system for coupon codes (rebuilt in-house)
  • Google Analytics for visitor tracking (replaced with self-hosted Umami and our own code)
  • Intercom for in-app support (rebuilt in-house)
  • Statuspage for external status notifications (rebuilt in-house)

We now depend on only two external services:

  • Stripe for payments (building a payment gateway would be insane)
  • SendGrid for email (reliable email delivery is hard)

These infrastructure SaaS providers have real moats. Everyone else, in my opinion, is in trouble.

There are several advantages to this “optimize-for-coding-agents” approach:

1. Better planning and execution.

The coding agent produces better plans because it has access to all code and configuration. It can “see” everything and reuse existing patterns (which is most of software development anyway). We can also place CLAUDE.md or AGENTS.md files in specific directories to guide it when needed.

2. Fewer brittle integrations.

Coding agents are better at reading and understanding code than third-party documentation. Instead of building SaaS integrations through trial and error, the agent writes exactly the feature we need in one shot. We also avoid backward-incompatible API changes or security updates for features we don’t even use.

3. Greater robustness.

Fewer dependencies mean fewer external failure points. When LaunchDarkly experienced an extended outage, much of our RAG cloud service was impacted. Now that feature flags live in our own codebase, they work as long as our Kubernetes nodes are running. If the entire cluster is down, we have bigger problems—but those are at least within our control.

4. Centralized management.

Instead of logging into five external services with five separate 2FA flows across multiple tabs, we now have a single pane of glass inside our own application. As long as I can log into our app, I can see everything.

5. A single CI/CD pipeline.

In a microservices setup, each service typically has its own repo and pipeline. Updating production requires orchestrating multiple releases. With everything in one place, none of that is necessary. If CI passes, we trigger CD and production is updated.

Strictly speaking, this last point is a benefit of using a monorepo. But we can use a monorepo because the coding agent can handle the complexity. We traditionally split repositories to manage human cognitive limits (Conway’s Law). With capable coding agents, that constraint is significantly reduced.

The main advantage is productivity. We can code, test, and deploy new features to production in hours instead of days. A new developer can enter the codebase with a coding agent and start delivering immediately. Junior developers are shipping features in days that would have taken senior engineers weeks in the past.

I believe most software development will move in this direction over the next few years. If you’re starting something new, design for what coding agents can do today. And if you think your project is too large or complex for this approach, consider what coding agents will be capable of six months from now. They’re only improving. Prepare accordingly.

P.S. We’ve already started building our own CRM. Sorry, HubSpot.

P.P.S LaunchDarkly we’re coming for you too.