memories/aipm-playbook-lovable-credit-capacity-management-e8e9976f.md

memory

Purpose

Handling procedure for Lovable monthly credit-cap increases and subscription user/team additions. Work-type label: REQUEST.

Who typically asks

Product, Marketing, and Web Dev staff building in Lovable against a deadline who hit the monthly credit limit, or teams wanting to add new users to the subscription.

Recognize at Intake

  • Requester reports hitting the monthly Lovable credit cap.
  • Request to add new users/teams to the Lovable subscription (e.g. via a merger).

Handling Procedure

  1. Ask for usage justification/pattern and current consumption before increasing allocation. Clarify hosting intent — design-mockup-only vs. actually hosting/serving the app — since hosting intent triggers the [[AIPM Playbook: Custom Business App Approval (Docebo App Scope Checklist / Security Risk Review)]] process.
  2. Check current usage level. Boost allocation for high-usage/blocked users (e.g. double to 300, or +40 to 90); defer low-usage requesters until consumption actually increases.
  3. For new users/teams on the paid subscription, calculate credit-burndown projections against the existing builder pool before approving.
  4. Add credits for the month and set a team reminder to reset to base-level credits the following month (Lovable has no "one-off" credit bumps).

Common Pitfalls

  • Approving credit/user growth without checking burndown math against the shared pool.
  • Not distinguishing "mockup only" from "production hosting" usage (different review requirements).

Typical Turnaround

Same day to a few days for individual boosts. Note: policy has evolved mid-series (individual caps → Finance-approved shared pool) — check current model before applying precedent from older tickets.

Reference

Confluence page ID 6030491652. Part of the AIPM request-type playbook set; see [[AIPM Intake SOP]] for overall triage/classification.