Polsia AI: The Operating Costs Behind the $20M Story

Why it matters

The figure that caught my attention was the $1.2 million monthly AI bill. Ben Cera describes taking Polsia to a $20 million annual run rate within a year, while also describing a business that had to change its infrastructure, pricing and reliability before it could keep expanding. For anyone building an AI product, those operating decisions are the useful part of the story.

Polsia describes its product as AI that runs company activities, from writing code to marketing and customer support. That broad promise creates a difficult operating problem. Customers can ask for very different amounts of work, and a straightforward subscription has to cover the resulting variation in compute, tool use and support.

The headline also needs a precise reading. A $20 million annual run rate describes an annualized revenue pace at a particular point. It does not establish that the business collected $20 million during the year or generated that amount in profit. Funding and company valuation are separate figures. The financial claims discussed here come from the founder's account; the video does not provide enough information to audit revenue quality, retention or profitability.

Key points

• 05:07 A solo founder can draw on an external engineering team. Cera describes partner engineers helping with bugs and product development. Anyone using this case as an operating benchmark should account for that capacity alongside direct headcount. Polsia's infrastructure relationship with Sapiom is also documented in a customer case study published by Blaxel.
• 05:39 Compute costs constrained the business model. The founder acknowledges that the existing bill was unsustainable. That raises a practical question for other builders: how much does each customer contribute after the work has been delivered? Adding customers with negative contributions increases the amount of funding an operation needs.
• 07:20 Model migration involves a quality threshold. Running open models on rented GPUs offered a route toward lower costs. The roughly $50,000 figure in this passage is an anticipated bill, rather than a verified final expense. It should not become a promised savings ratio for another product with a different workload.
• 10:08 A price cut creates a volume requirement. Cera reports cutting the subscription from $50 to $20, followed by an initial decline in annualized revenue. Holding everything else constant, preserving subscription revenue at that price requires 2.5 times as many subscribers. The infrastructure must then support the additional customers and their work.
• 08:27 Distribution involved deliberate human coordination. The launch included outreach to media, investors and people who could amplify the announcement. That matters when assessing what made growth possible: the account includes a coordinated campaign and sustained commercial effort, both of which require time and resources.
• 12:24 Reliability became a major development priority. The founder describes spending most of his time stabilizing the platform. For a software builder, this is a familiar allocation problem. Additional capabilities can attract customers, while dependable execution determines the effort required to keep serving them.

How to apply

Use Polsia AI to frame a customer contribution model

I would start with a small spreadsheet. For each customer, record monthly revenue, model spending, paid tool calls, variable infrastructure costs and support effort. Keep fixed expenses visible separately so you can see how much each subscription contributes toward running the business.

Consider this hypothetical example:

| Monthly amount per customer | Typical usage | Heavy usage | | --- | ---: | ---: | | Revenue | $49 | $49 | | AI model costs | $10 | $30 | | Other variable expenses | $8 | $8 | | Contribution before fixed costs | $31 | $11 |

The contribution margin falls from roughly 63% to 22%. Other variable expenses stay constant in this illustration to isolate model spending. In practice, heavier usage might also increase support and infrastructure costs. Neither figure establishes profitability, because fixed expenses and any omitted costs still have to be paid.

For a Brazil-based product charging in reais and paying providers in dollars, I would add an exchange-rate stress scenario. Increase the assumed exchange rate by 20% and recalculate contribution. That is a planning assumption, rather than a forecast, and it reveals how much room the current price provides.

Compare the cost of finished work

A cheap response can become expensive if it triggers repeated attempts or requires substantial manual repair. My preferred measure would be:

Cost per approved task = cost of all attempts and reviews ÷ approved tasks.

Choose 20 representative tasks from your project before comparing models. Include ambiguous instructions, integration failures, Portuguese requests if relevant, and situations where execution should stop. Define what an acceptable result looks like before running the comparison.

Then record spending, elapsed time and human corrections for every attempt. A less expensive model may be sufficient for a specific task, while another task justifies a more capable model. The comparison gives you evidence for that routing decision.

I would evaluate rented GPUs after establishing those workload measurements. Include idle capacity, maintenance and engineering time in the comparison with an API-based setup. A lower token cost alone does not capture the operating burden.

Run a 14-day pilot with one defined outcome

During the first two days, select a task with a clear beginning and end. Preparing a proposal from structured inputs is a useful example. Record the current completion time and common mistakes so the pilot has a baseline.

From day three through day seven, run the agent with human review. Keep a record of the result, cost and required corrections. Set a retry limit and a stopping condition so a broken integration cannot produce an open-ended sequence of paid attempts.

During the second week, expand usage gradually. Track new users separately from returning users. Observe whether people return to the output without reminders and whether support effort changes as usage grows.

Before starting, define a quality target, a maximum cost per completed task and an acceptable amount of human review. These thresholds make the decision to continue easier to assess. I would increase autonomy when completed work meets those conditions consistently. That is the operating lesson from Polsia I would carry into another project.