SaaS vs Open Source Dev Tools: AI Rules

Managed SaaS vs Community Open Source

SaaS developer tools: Vercel (hosting), Neon (Postgres), PlanetScale (MySQL), Auth0 (authentication), Sentry (error tracking), Stripe (payments), SendGrid (email). You pay: a monthly subscription or per-usage fee. You get: a managed service with: dashboard, SDK, documentation, support, uptime SLA, and automatic updates. The integration: via SDK or API (import { neon } from '@neondatabase/serverless'). The trade-off: vendor lock-in (switching costs), subscription costs, and dependency on the vendor's continued operation.

Open-source alternatives: Coolify (self-hosted PaaS like Vercel), PostgreSQL (self-managed database), Keycloak (self-hosted authentication), GlitchTip (self-hosted Sentry alternative), Plunk (self-hosted email). You pay: $0 for the software (hosting costs for your server). You get: full source code, no vendor dependency, no subscription fees, and customization freedom. The integration: via library or direct connection (import { Pool } from 'pg'). The trade-off: operational overhead (you manage: updates, scaling, backups, monitoring).

Without tool-type rules: the AI generates SaaS SDK imports for a self-hosted setup (import { neon } from '@neondatabase/serverless' when the project uses self-hosted Postgres with pg), or self-hosted connection patterns for a SaaS setup (new Pool({ connectionString }) when the project uses Neon's serverless driver). The tool type determines: which library to import, which connection pattern to use, and which configuration to reference.

Integration: SDKs vs Standard Libraries

SaaS integration: vendor-specific SDKs. Neon: import { neon } from '@neondatabase/serverless' (HTTP-based, edge-compatible). Auth0: import { Auth0Client } from '@auth0/nextjs-auth0' (pre-built auth flows, session management). Sentry: import * as Sentry from '@sentry/nextjs' (automatic error capture, source maps). Each SDK: is maintained by the vendor, optimized for their service, and may include vendor-specific features (Neon branching, Auth0 rules, Sentry release tracking). AI rule: 'SaaS: use vendor SDKs. Neon: @neondatabase/serverless. Auth0: @auth0/nextjs-auth0. Sentry: @sentry/nextjs.'

Open-source integration: standard libraries. Postgres: import { Pool } from 'pg' (standard Postgres driver, works with any Postgres instance). Auth: import NextAuth from 'next-auth' (open-source auth library, self-hosted providers). Error tracking: import { captureException } from './lib/error-tracking' (custom wrapper around your self-hosted GlitchTip or logging). Each library: is community-maintained, works with any compatible backend, and does not lock you to a vendor. AI rule: 'Open-source: standard libraries. pg for Postgres. NextAuth for auth. Custom wrappers for error tracking and email.'

The integration rule prevents: the AI importing @neondatabase/serverless for a self-hosted Postgres (Neon SDK talks to Neon's HTTP endpoint, not a standard Postgres instance), using pg driver for Neon (pg works but the serverless driver is: edge-compatible and optimized for Neon), or importing @auth0/nextjs-auth0 when the project uses Keycloak (Auth0 SDK connects to Auth0's service, not Keycloak). The import is: tool-determined. One wrong import: connects to the wrong service or fails entirely.

• SaaS: vendor SDKs (@neondatabase/serverless, @auth0/nextjs-auth0, @sentry/nextjs)
• Open-source: standard libraries (pg, next-auth, custom wrappers)
• SaaS SDKs: vendor-optimized, edge-compatible, vendor-specific features
• Standard libraries: community-maintained, works with any compatible backend, no lock-in
• AI error: Neon SDK for self-hosted Postgres (wrong endpoint). pg for edge Neon (not edge-compatible)

Vendor Lock-In: Migration Awareness

SaaS lock-in spectrum: low lock-in (Neon — standard Postgres, migration: change the connection string to any Postgres), medium lock-in (Vercel — Next.js works anywhere, but Vercel-specific features like edge middleware and ISR may need adaptation), high lock-in (Auth0 — Auth0 rules, actions, and user database are Auth0-specific, migration requires: reimplementing auth flows). The rule should note: the lock-in level per service so the AI avoids: deep integration with high-lock-in vendor-specific features when portability matters.

Open-source portability: low lock-in by design. Self-hosted Postgres: any Postgres-compatible tool works. NextAuth: standard OAuth, works with any provider. Self-hosted error tracking: any logging format works. The integration is: against standards (SQL, OAuth, SMTP), not vendor APIs. Migration: change the host/connection, not the code. The trade-off: fewer vendor-specific optimizations (no Neon branching, no Auth0 rules engine, no Sentry release tracking).

The lock-in rule for AI: 'Use standard interfaces where possible. Postgres SQL: works with Neon, Supabase, self-hosted, or any Postgres. OAuth: works with Auth0, Keycloak, or any OIDC provider. Avoid: vendor-specific features (Neon branching API, Auth0 rules) unless the feature is critical and migration is not planned. If using vendor features: document the lock-in in CLAUDE.md so the AI and future developers know which code is vendor-specific.'

• Low lock-in: Neon (standard Postgres SQL), SendGrid (standard SMTP fallback)
• Medium lock-in: Vercel (Next.js portable, edge middleware less so), Stripe (payment API portable-ish)
• High lock-in: Auth0 (rules, actions, user DB are service-specific), Firebase (Firestore is proprietary)
• Open-source: low lock-in by design (standards-based: SQL, OAuth, SMTP)
• AI rule: 'Use standard interfaces. Document vendor-specific features. Note lock-in level per service'

When to Choose Each Approach

Choose SaaS when: you want to ship fast (SaaS tools are: configured in minutes, not days), your team lacks ops expertise (no one to manage Postgres, Keycloak, or monitoring infrastructure), the subscription cost is: less than the ops cost of self-hosting (a $50/month SaaS saves: 10+ hours/month of ops work), or you value: reliability guarantees (SaaS uptime SLAs, automatic failover, managed backups). SaaS is: the default for most startups and small teams.

Choose open-source when: cost matters at scale (self-hosted Postgres at $50/month server cost vs $200/month Neon bill at high usage), compliance requires self-hosting (data residency, air-gapped environments, specific certifications), you want full control (custom configurations, kernel tuning, specific versions), or you want: no vendor dependency (the software runs on your servers, under your control, forever). Open-source is: the choice for cost-conscious, compliance-driven, or control-focused teams.

The hybrid is most common: SaaS for: services you do not want to manage (auth, payments, email, error tracking — high complexity, low differentiation). Open-source for: your core database and application hosting (where you need: full control, customization, and cost optimization at scale). The AI rule: specifies which services are SaaS and which are self-hosted. The imports, configuration, and connection patterns: differ per service.

• SaaS: ship fast, no ops expertise, subscription < ops cost, reliability guarantees
• Open-source: cost at scale, compliance, full control, no vendor dependency
• Hybrid most common: SaaS for auth/payments/email + self-hosted for DB/hosting at scale
• Startup default: all SaaS (ship fast). Growth: hybrid (optimize costs). Enterprise: more self-hosted (control)
• The rule specifies: which services are SaaS and which are self-hosted per component

Rule Templates for Each Approach

SaaS stack CLAUDE.md: '# Infrastructure (SaaS Stack). Hosting: Vercel (Next.js auto-deploy, edge functions). Database: Neon Postgres (@neondatabase/serverless, HTTP driver). Auth: Auth0 (@auth0/nextjs-auth0). Email: SendGrid (@sendgrid/mail). Error tracking: Sentry (@sentry/nextjs). Payments: Stripe (@stripe/stripe-js + stripe). All services: configured via provider dashboards. Env vars: in Vercel project settings. No Terraform, no Docker, no self-hosting.'

Open-source stack CLAUDE.md: '# Infrastructure (Self-Hosted). Hosting: Docker + Coolify (self-hosted PaaS). Database: PostgreSQL (pg driver, self-managed, PgBouncer for pooling). Auth: NextAuth with self-hosted Keycloak OIDC provider. Email: Plunk (self-hosted) or SMTP relay. Error tracking: GlitchTip (self-hosted Sentry alternative). Payments: Stripe (SaaS — no open-source payment processor is viable). Deploy: Docker Compose for development, K8s for production. Terraform for infrastructure provisioning.'

Note: even the open-source stack uses Stripe (SaaS) for payments — some services have no viable self-hosted alternative. The AI rule: should be honest about which services are self-hostable and which are SaaS-only by necessity. Payments: always SaaS (Stripe, no alternative). Auth: self-hostable (Keycloak). Database: self-hostable (Postgres). Hosting: self-hostable (Coolify, Docker). The rule maps: each service to its tool and hosting model.

Tool Model Summary

Summary of SaaS vs open-source dev tools AI rules.

• SaaS: vendor SDKs, dashboard config, subscription cost, managed ops, vendor lock-in risk
• Open-source: standard libraries, IaC config, server cost, self-managed ops, no lock-in
• Integration: SaaS = @vendor/sdk. Open-source = standard library (pg, next-auth, custom)
• Lock-in: low (Neon, standard SQL) to high (Auth0, proprietary rules). Document per service
• Hybrid: SaaS for complex non-differentiating services + open-source for core DB and hosting
• Even open-source stacks use some SaaS: Stripe for payments has no viable self-hosted alternative
• Default: SaaS for startups (ship fast). Open-source grows with: scale, compliance, and cost optimization
• AI rule: per-service mapping of tool name + hosting model + import library