Stop Gluing SaaS Together: Build Your Own Engineering Platform

Here is a bill that should make any engineering leader uncomfortable: $47 per seat for Linear, $10 per seat for Confluence, $22 per seat for LaunchDarkly, $31 per host for Datadog, $20 per seat for Backstage's managed offering, and whatever Vercel charges you this month for exceeding your bandwidth cap. Multiply by a 30-person team and you are burning north of $15,000/month on tools that do not talk to each other. Each one has its own auth model, its own API conventions, its own webhook format, and its own way of defining what a "project" is. You are not building software. You are gluing SaaS together.

We decided to stop.

The Real Cost Is Not the Invoice

The subscription fees are painful, but they are not the real problem. The real problem is context fragmentation. Your tasks live in Linear. Your documentation lives in Confluence. Your service catalog lives in Backstage. Your feature flags live in LaunchDarkly. Your observability data lives in Datadog. Your deployments live in Vercel or Argo or whatever you duct-taped together last quarter.

When an incident happens, your on-call engineer opens six browser tabs. They check the service catalog to understand ownership. They check the task tracker to see if someone was already working on it. They check the docs to understand the service architecture. They check the feature flag dashboard to see what changed. They check the observability stack to find the actual error. And they check the deployment tool to see if a recent rollout caused it.

Six tools. Six logins. Six different mental models. That is not developer experience. That is developer tax.

What We Built Instead

Riven is a single, self-hosted Internal Developer Platform that replaces the entire stack. Not with a thin wrapper or an aggregation layer — with actual, purpose-built services that share a common identity model, a common API layer, and a common CLI.

Linear/Jira becomes our Task Service — kanban boards, task tracking with comments, milestones, and full audit history. Same workflow, zero per-seat fees.

Confluence/Notion becomes our Pages Service — spaces, pages with version history, granular permissions, and rich block-based content. Your docs live next to your services, not in a separate universe.

Backstage/OpsLevel becomes our Dev Center — a real service catalog with deployment management, environment configuration, and health monitoring. Not a plugin marketplace you spend three sprints configuring.

LaunchDarkly becomes environment management built into the platform. Feature flags and environment variables managed through the same CLI and dashboard you already use for everything else.

Datadog/New Relic becomes built-in observability powered by Grafana, Prometheus, Loki, and Jaeger. Self-hosted, so your telemetry bill does not scale with your log volume.

LangChain/CrewAI becomes our Agent Orchestration System (AOS) — four agent archetypes with durable execution, skill registries, and MCP integrations. AI agents that actually understand your platform because they live inside it.

Separate auth providers become a unified Identity + Authorization layer powered by Better Auth and OpenFGA. One session, one token, one permission model across every service.

The Architecture That Makes It Work

We run 20 microservices on EKS, every one of them built with a proto-first approach. Protocol Buffers are the source of truth. We define the API in .proto files, run codegen, and implement. The result: zero schema bugs in production. The types your frontend uses are literally generated from the same file your backend implements.

Every service ships with a 2-line Dockerfile. Not a 2-stage, not a 2-page — two lines. Our node-service-base image handles dependency resolution, tree-shaking, and production optimization through ONBUILD directives. Developers do not write Dockerfiles. They write services.

All of this is controlled through a single CLI: riven. Deploy a service? riven dev-center service deploy. Start a rollout? riven dev-center rollout start. Generate proto types? riven proto generate. There is no context switch. There is no "let me check the docs for the kubectl flags." One tool, one workflow.

We use Connect RPC across the board, which gives us the same type-safe API calls in the browser and between backend services. No REST translation layer. No GraphQL resolver sprawl. Just typed RPC calls from end to end.

Self-Hosted AI, Not Rented API Calls

Our AI platform runs self-hosted models — not GPT API calls billed per token. We run inference on our own infrastructure, which means our AI agents can process internal code, documents, and telemetry data without shipping it to a third party. The Agent Orchestration System coordinates four distinct agent archetypes with durable execution, meaning agents can run multi-step workflows that survive restarts and failures.

This is not possible when your AI layer is a SaaS wrapper around someone else's API. You need the models close to the data, and you need the orchestration close to the platform.

The Economics Are Simple

A typical SaaS stack for a 30-person engineering team runs $12,000-$18,000/month when you add up all the per-seat and per-host charges. Our EKS cluster — running all 20 services, the AI platform, observability, and the frontend — costs a fraction of that. And the marginal cost of adding a new engineer is zero. No new seats to buy. No usage tiers to bump into.

More importantly, you own the data. Your task history, your documentation, your service catalog, your telemetry — all of it lives in your own databases, in your own AWS account. No vendor lock-in. No data export drama. No "enterprise plan required" to access your own audit logs.

This Is Not For Everyone

If you are a 5-person startup shipping your first product, use Linear and Notion and Vercel. They are great tools. The SaaS tax at that scale is worth the speed.

But if you are a growing engineering org that is already drowning in integrations, spending hours on cross-tool workflows, and watching your SaaS bill climb every quarter — it is time to ask whether you are building your product or just maintaining someone else's.

We chose to build our own. And we have not looked back.