按物业还是按积分：媒体 SaaS 定价页面背后的单位经济学选择

There are two ways to price an AI media tool, and the choice quietly decides what your customer optimizes for. You can bill per operation, usually dressed up as credits, or you can bill per unit of the customer's actual work. We build CasaNova Labs, an AI studio for real estate photo and video editing, and we bill per property rather than per credit. Here is the reasoning, because it is a real tradeoff and not obviously the right call for everyone. What per-credit optimizes for

A credit is a unit of your cost, not the customer's value. When a tool bills per credit, the customer's incentive is to spend fewer credits, which means generating fewer images, which is the opposite of what makes their listing sell. Every render becomes a small yes-or-no budgeting decision. For a per-credit example with real, checked numbers, Roomagen bills by the credit and spends two credits per delivered image, which resolves to roughly $0.40 down to $0.23 per image depending on tier. The buyer's mental math is entirely at the image level: every render is a credit-to-image conversion done in your head before you click.

That model is honest and works fine when usage is spiky and unpredictable. It maps cost to consumption, which is exactly what you want if a customer might run one image this month and four hundred the next. The downside is behavioral: it makes the customer ration the very thing your product is for. What per-property optimizes for

A property is a unit of the customer's work. A real estate agent does not think in renders, they think in listings. Billing per property, with a generous per-listing image allowance, changes the incentive: within a listing, generating one more staged room or one more sky replacement costs nothing marginal, so the agent does the thing that actually helps the sale. The unit of billing matches the unit of value.

The cost to us of that model is variance. Some agents will use the full allowance on every listing, some a fraction, and we carry the spread rather than passing it through per render. That is a deliberate cost we take on to remove the per-image hesitation. The full grid and where the per-listing line lands is on the pricing page, and how it compares against the per-credit tools is laid out in the alternatives breakdown. The engineering consequence nobody mentions

The billing unit leaks into the architecture. Per-credit billing forces a metering system: every operation is counted, reconciled, and shown to the user, and that counter is now on the critical path of every render. Per-property billing moves the accounting boundary up to the listing, so the render path itself carries no metering, which is simpler and faster and removes a class of "why was I charged for a failed generation" support tickets. The pricing model you pick is also a system-design decision, and the per-unit-of-value model happens to have the cleaner internals. When each is right

Per-credit wins when consumption is genuinely unpredictable and the customer is technical enough to reason at the operation level, an API product for developers, say. Per-unit-of-value wins when the customer thinks in their own domain object and you want them to use the product freely rather than ration it. For real estate, the domain object is the listing, so that is the unit we bill. If you are designing a media SaaS, the question to answer first is not what to charge, it is what unit your customer already counts in, and whether your incentive should push them to do more of the thing or less.

You can run the per-property model against ten photos without a card at CasaNova Labs.