Daily caps do not multiply the monthly allowance
The founder’s credit clarification uses Tier 2 as the example: the daily cap permits a concentrated building session, but the monthly pool remains the total. Spending the daily maximum for ten days would exhaust that pool. The remaining days of the month do not add another daily allocation.
Current pricing documentation says AI messages and integration actions can use credits, with cost varying by model and action. This makes “one prompt equals one credit” an unsafe planning rule. A detailed initial request, several corrections and an integration fix are one business outcome but several chargeable steps.
The official pricing page says plan credits reset monthly without rollover. Purchased packs are separate and do not expire. AppSumo’s listed 100-credit add-on is $15 and non-refundable; the founder confirms it is a one-time balance, not an increase to every future day or month. The direct site also lists other pack sizes. Check the current account purchase screen rather than assuming every checkout offers identical packs.
The finished app has its own operating budget
App count is only one dimension. Server credits cover server-side work such as workflows and background actions; requests measure app activity such as screen loads and data operations. Heavier work can use more server credits while still being one request. Neither counter is the same as the AI building balance.
The founder confirms that hosting resources are cumulative across the workspace. If two apps together store 4,800 rows on Tier 1, their remaining room is 200 rows—not another 5,000 for each app. Likewise, ten apps on Tier 3 share the displayed capacity rather than each receiving it.
A request forecast is necessarily approximate. Suppose twenty staff each cause ten billable requests on twenty working days: that is 4,000 requests before background jobs, public traffic or additional reads and writes. This is a budgeting example; a single screen can create more than one operation. Watch actual counters during evaluation.
A September founder answer describes an alert and two-week grace period after hosting limits are crossed, with upgrading or extra capacity as options. Treat that as dated guidance, not a contractual uptime guarantee. Ask what the app does after the grace period and who receives the billing alert before making it a critical business system.
One updated buyer report describes earlier invented test results and incorrect data flow, then a substantially improved rebuild. Treat that as a reason to check the actual output: submit a known input, inspect the stored record, verify the returned value and repeat with a user who should not have access. An AI-generated “passed” message is not a substitute for observing the app.
