Open Core Models: Drawing the Line Between Free and Paid

The open core model has become the de facto playbook for infrastructure startups. Companies like Supabase, Hasura, and Mattermost build their entire strategy around it: release core functionality as open source, monetize advanced features for enterprises.

But this balance is fragile. Get it wrong, and you'll face backlash. Your community feels betrayed. Your paid tier sits empty. Your open source project loses momentum.

This post explores how to draw that line thoughtfully—and the real costs when you don't.

The Core Tension

Open core works because it solves a genuine problem: giving developers a free way to evaluate your product while funding engineering teams through enterprise features.

But users quickly spot bad faith moves. When core functionality feels artificially limited, or when you move features from free to paid between versions, trust evaporates.

The question isn't whether to have a paid tier. It's: what features belong in open source, and what belongs behind a paywall?

Where Most Companies Go Wrong

Many teams restrict features based on where the enterprise money is, not where the product naturally splits. They ask: "What will customers pay for?" instead of asking: "What makes the open source version genuinely valuable on its own?"

This creates a free tier that feels incomplete. Developers use it, hit limitations immediately, and move to competing products rather than upgrading.

The successful approach inverts this: build a complete, production-ready open source product. Then add enterprise features on top—team management, advanced analytics, compliance tooling, managed hosting.

Practical Boundaries

Here's how to think about feature placement:

Open Source Should Include

• Core functionality that solves the fundamental problem
• Everything needed for individual developers and small teams
• All APIs and extensibility points
• Community-driven features (the differentiator versus proprietary tools)

Enterprise/Paid Should Include

• Managed infrastructure and hosting
• Advanced user and permission management
• Audit logs, compliance reporting, SSO
• High-volume support tiers
• Specialized tooling for specific industries

Consider how Postgres handles this: the database engine is fully open source and production-grade. Companies monetize managed services (AWS RDS, Heroku) and premium support, not core database features.

A Real Example

If you're building an API gateway, your open source version should handle routing, rate limiting, and basic authentication:

typescriptCopy
interface GatewayConfig {
  routes: Route[];
  rateLimit?: RateLimitConfig;
  auth?: AuthConfig;
}

class ApiGateway {
  private config: GatewayConfig;

  async handleRequest(req: Request): Promise<Response> {
    // All core functionality here
    const route = this.matchRoute(req.url);
    await this.checkRateLimit(req.clientId);
    await this.authenticate(req);
    return this.forward(req, route);
  }
}

Your paid tier adds advanced analytics, multi-region deployment, and advanced policy management—not these fundamental capabilities.

The Sustainability Question

LavaPi works with teams building open source businesses. What we consistently see: companies that treat open source as a real product (with real maintenance, real documentation, real security patches) build stronger paid tiers. The reverse also holds—teams that treat open source as marketing window dressing watch both the free and paid products suffer.

Your open source tier sets expectations. Users evaluate you based on code quality, responsiveness to issues, and roadmap transparency. Cutting corners on the free version signals that your paid version isn't worth it either.

The Bottom Line

The line between free and paid shouldn't be artificial scarcity. It should be specialization.

Give developers a complete, excellent open source product. Then build enterprise features that solve problems the open source version doesn't claim to solve: operational complexity, compliance, and scale.