How to Add AI Video as a Paid Product to Your Real Estate SaaS
If you sell software to real estate agents, listing video is one of the few features your customers already want, already understand, and mostly cannot produce. Here is how to package it, price it, and meter it without building video infrastructure.
Why Video Is an Unusually Good SaaS Add-On
Most features you can bolt onto a real estate software product are hard to charge for individually. They improve the core product, which is good, but customers experience them as part of what they already pay for. Video is different because it produces a discrete artifact the customer can hold, share, and attribute value to. That makes it chargeable in a way that a better dashboard is not.
It also solves a problem your customers are already aware of and already failing at. Agents know video performs. The reason they do not post it is that producing it means either hiring someone or learning editing software. A feature that eliminates both steps is not a nice-to-have, and four things follow from that.
It is a feature customers already want to buy
Listing video is not a capability you have to educate the market about. Agents know they should be posting video and mostly are not, because production is the barrier. A button inside software they already pay for removes that barrier, which means the sales conversation is about price rather than about whether video matters.
It creates a natural upgrade tier
Most real estate SaaS products struggle to justify a higher plan tier because the features that differentiate tiers are abstract — more contacts, more automations, more seats. Video is concrete and visibly valuable, which makes it one of the more effective things you can put behind an upgrade.
The cost side is unusually legible
Two endpoints cost credits and six are free. That means your cost of goods for a video feature is exactly one credit per clip plus one per merge, and status polling — the thing you will do most often — is free. You can price with confidence because you know your unit cost before you write the feature.
Time to market is weeks, not quarters
You are building an orchestration layer over a REST API, not a video pipeline. No model evaluation, no GPU capacity planning, no FFmpeg infrastructure, no on-call rotation for stuck renders. The build is conventional application work your existing team can already do.
Know your unit cost before you design the feature
One credit per generated clip, one credit per reel merge, and nothing for uploads, status polling, job lists, or balance checks. Cap a listing at eight photos and your cost is exactly nine credits — every listing, every customer, every time. Almost every packaging mistake in this space comes from not fixing that number first.
Five Packaging Models, With Their Failure Modes
There is no single correct answer here — it depends on your existing pricing architecture and how usage-sensitive your customers are. But each model has a specific way it goes wrong, and knowing that in advance is worth more than picking the theoretically optimal one.
Per-listing pricing
Charge a flat fee per listing video. Your cost is fixed because you cap the photo count, so the margin is identical on every unit.
The customer has to make a purchase decision every time, which suppresses usage and therefore habit formation.
Monthly credit allotment
Bundle a number of videos into each plan tier. Predictable revenue, predictable cost, and a natural upgrade path when customers hit the ceiling.
Unused allotment creates a perception of waste unless you let it roll over, and rollover complicates your own credit forecasting.
Add-on subscription
A separate monthly line item for the video module. Clean attribution — you know exactly what the feature earns.
A second purchase decision after they already bought your product, which converts worse than bundling into a tier.
Bundled into the top tier
Strongest upgrade driver. Video becomes the reason to move from mid to top tier, lifting your average revenue per account.
You lose per-unit revenue on heavy users, so you must cap generation somewhere or a few accounts will define your costs.
Unlimited flat rate
Simplest thing to market and the easiest for a customer to say yes to.
Your cost scales with usage while revenue does not. This is the one packaging model that reliably produces margin surprises.
For most products, a monthly allotment bundled into an existing tier is the strongest starting point. It avoids a second purchase decision, it caps your exposure, and hitting the ceiling becomes a natural upgrade trigger rather than a support complaint. Reserve unlimited flat-rate pricing for the case where you have measured real usage and know the distribution has a short tail.
The Integration Is Smaller Than You Think
The whole feature reduces to moving photos into storage, creating jobs, tracking them, and merging results. Start by reserving upload slots for a listing in one free call, then PUT the bytes:
GET /api/v1/presigned-urls?count=8
{
"bucket": "api-uploads",
"uploads": [
{ "path": "...", "presignedUrl": "https://...", "publicUrl": "https://..." }
]
}Then one paid call per photo. Generate the prompt from listing metadata you already store — property type, room label, style — so the customer does not have to write anything:
POST /api/v1/videos
{
"prompt": "smooth cinematic reveal of a modern living room",
"imageUrl": "<publicUrl>",
"effects": ["push_in", "pan_left"],
"duration": 5
}
{ "jobId": "uuid", "status": "pending", "creditsCharged": 1 }Record that creditsCharged against the customer account immediately. This is the line that keeps your billing honest, and skipping it is the most common reconciliation problem in usage-metered features. Then merge with your customer's branding applied at runtime:
POST /api/v1/reels
{
"videoJobIds": ["uuid-1", "uuid-2", "uuid-3"],
"orientation": "portrait",
"musicType": "lofi",
"textOverlay": { "text": "123 Main Street, Miami", "fontSize": 56 },
"ending": { "text": "Contact us today!", "duration": 3 },
"logo": { "url": "<customerLogoUrl>", "scale": 15 }
}That logo field is quietly important to your product story. Because branding is set per request, the output carries your customer's identity rather than ours or yours — which means the feature strengthens their brand and your product simultaneously.
Metering Rules That Protect Your Margin
Credits are pooled across every API key on your account, so there is no built-in per-customer boundary. That boundary is your responsibility, and these seven rules cover the cases that actually cause problems.
- 1Cap photos per listing in your own code — this is your primary cost control, not a user preference.
- 2Record the credit charge against the customer account the moment a job is created, not when it completes.
- 3Count a regeneration as a new billable unit, or explicitly give one free retry and track it.
- 4Check the customer's remaining allotment before creating jobs, so you never start a batch you cannot finish.
- 5Poll the credits endpoint on a schedule and alert internally well before the pool runs dry.
- 6Store the jobId, the listing, the customer, and the credits charged in one row you can reconcile against invoices.
- 7Treat failed renders as non-billable — the credit is refunded automatically, so your ledger should match.
Regeneration deserves specific attention because it is where costs quietly double. A customer who does not love the first reel will try again, and if retries are free and untracked your cost per listing is no longer nine credits. Either bill regenerations or grant exactly one and enforce it. Monitor the pool with the free balance endpoint:
GET /api/v1/credits
# Free. Read total, used, and remaining. Alert
# internally at a threshold so you top up before
# customer-facing jobs start getting refused.Because failed renders refund the credit automatically, your ledger only ever needs to account for successful generations — which removes an entire class of billing dispute you would otherwise have to handle manually.
A Seven-Step Launch Plan
The ordering here is deliberate: pricing hypothesis first, then a validation build, then real usage data, and only then a final price. Most teams do this backwards and end up repricing after launch.
- 1Pick one packaging model and write down your cost per unit and target price before building anything.
- 2Build a single internal script that turns a listing's photos into one branded reel, to validate the pipeline.
- 3Ship it to ten friendly customers as a free beta and watch how many listings they actually run through it.
- 4Instrument everything: videos per account, per listing, regeneration rate, and time from signup to first video.
- 5Set your cap and price based on the beta's real usage distribution rather than your original guess.
- 6Launch as a paid tier or add-on with the sample reels from beta customers as the marketing asset.
- 7Add automatic generation triggered by listing creation once manual adoption proves the value.
Step four is the one people skip. The metric that predicts whether this feature drives revenue is not total videos generated — it is what share of a customer's new listings get a video. If that number is high, video has become part of their workflow and they will not churn off the tier that provides it. Full endpoint schemas, effect options, and error codes are in the API documentation, and the developer overview with plan tiers is on the API page.
Validate the feature before you price it
Activate an API plan, wire up one listing end to end, and put a real branded reel in front of ten customers this week.
Related Articles
How CRM and IDX Platforms Win Customers with AI Video
Competitive differentiation, demo strategy, and reducing churn with a video module.
API Keys, Authentication and Credits
The pooled credit model, per-customer accounting, and safe key rotation.
Build a Real Estate Video App with the API
The full five-stage pipeline from authentication to finished branded reel.