Why Config First

Most billing integrations start in a dashboard. You create Stripe products, copy IDs into code, write webhooks, then slowly build an entitlement layer next to the payment layer.

That works, but it creates a split brain:

• Product behavior lives in code.
• Billing shape lives in a dashboard.
• Runtime access logic lives in helper functions.
• Stripe IDs leak into routes and UI.
• Webhook behavior becomes difficult to review.

Guapocado starts from the other direction. The product billing model lives in your repository.

Billing Is Product Code

When billing is config-first, a plan change becomes a code review:

{
  key: "pro",
  pricing: {
    mode: "recurring",
    type: "flat",
    amount: 4900,
    currency: "usd",
    frequency: "month",
  },
  entitlements: {
    "advanced-analytics": true,
    "api-calls": { included: 100000 },
    seats: { included: 10 },
  },
}

The diff answers practical questions:

• What changed?
• Which customers will see different access?
• Which code paths check these entitlement keys?
• Does the new model match the feature launch?

The Dashboard Is Not the Source of Truth

Guapocado still uses a hosted dashboard and API. The dashboard is for managing keys, environments, Stripe connections, approvals, and operational visibility.

The config remains the source of truth for the billing model.

That means a developer can clone the repo, read billing.config.ts, and understand what the product sells without clicking through Stripe objects.

Stripe Is Still There

Guapocado is not trying to hide that payments exist. Stripe is still the payment processor.

The difference is that application code should usually not care about:

• Stripe product IDs.
• Stripe price IDs.
• Subscription item IDs.
• Which webhook event created the current state.

Application code should care about:

• productKey
• customerId
• feature keys
• meter keys
• limit keys

Why This Helps Newer Teams

Billing can feel like learning three things at once:

• payment processing
• product packaging
• access control

Guapocado narrows the first integration down to product concepts. You can model “Pro has 10 seats and 100,000 API calls” before you need to become fluent in Stripe subscriptions, prices, invoices, and webhook retry behavior.

As your app grows, the lower-level details are still available. The starting point is simply smaller.

Why This Still Helps Experienced Teams

Experienced teams can wire Stripe directly. Guapocado is useful when the team wants the entitlement model to stay consistent across:

• backend route checks
• React UI gates
• checkout flows
• webhook projection
• generated OpenAPI and schema surfaces
• framework integrations

The value is not that Stripe is impossible. The value is that entitlement logic is easy to get subtly wrong and hard to keep synchronized.