Why this matters

If you are a founder, product manager, or first-time streaming CTO, the number you are usually quoted — "an OTT platform costs $150,000 to build" — answers the wrong question. The build is a one-time event; the platform then runs every month for years, and the monthly bill is where streaming businesses live or die. This article gives you the full cost model: the one-time build, the recurring run, the formula that drives each line, and a worked example with the arithmetic shown out loud. By the end you will be able to read any vendor quote, find the egress line (or notice it is missing), and sanity-check whether your planned subscription price actually covers the cost of serving a viewer. The companion spreadsheet lets you plug in your own catalog size, audience, and bitrate and see the monthly number move.

The two cost shapes: build once, run forever

Every cost in an OTT platform falls into one of two buckets, and keeping them separate is the single most useful habit in this whole topic.

The first bucket is the one-time build: the engineering effort to create the thing. Designing and coding the viewer apps (web, phone, tablet, smart TV, streaming sticks), the back-end services (the catalog, the user accounts, the entitlement service that decides who may watch what), the billing integration, and the content-management tools your operators use. You pay this once to get to launch, then again in smaller increments as you add features. Think of it as the cost of constructing a shop: you pay to build it before you sell anything.

The second bucket is the recurring run: the monthly cost of keeping the platform serving video. Encoding new content, storing the encoded files, paying the content delivery network to deliver every stream, paying the digital-rights-management service for every licence it issues, and paying for the servers behind your apps. This bill arrives every month whether or not you ship a single new feature, and it grows as your audience grows. This is the shop's rent, electricity, and stock — and for a streaming business, the "electricity" bill is enormous.

The classic mistake is to treat the build quote as "the cost of the platform". It is not. It is the cost of the door. A platform that costs $200,000 to build can easily cost $200,000 a year to run once it has a real audience, and the run cost is the one that decides whether your unit economics work. We will price the build, then price the run, then put them together in a worked example.

OTT cost map showing one-time build stages and recurring run stages across the streaming pipeline, with delivery flagged as the dominant cost. Figure 1. The OTT cost map. Each box in the pipeline carries either a one-time build cost, a recurring run cost, or both; delivery (egress) is the recurring line that dominates everything else at scale.

The one-time build: what it costs to get to launch

The build cost is mostly engineering time, so it scales with how many surfaces you support and how custom the product is. Three rough tiers exist in the 2026 market, and they are wide ranges because "an OTT platform" can mean very different scopes.

A minimum viable product — web plus one or two mobile apps, a basic catalog, subscription billing, and a single content type — typically runs $50,000–$90,000 and takes four to six months. A standard custom platform for an entertainment business — multi-platform apps, personalization, content operations tooling, and proper CDN/DRM integration — typically starts at $150,000–$350,000 and takes nine to fifteen months. These ranges come from current OTT-development market surveys; treat them as orientation, not a quote, because they swing with team rate, region, and scope.

The cost driver inside the build that surprises people is the device matrix. Each living-room and mobile target is a separate codebase with its own language, store rules, and certification process. Building native apps across web, iOS, Android, Apple TV, Roku, Samsung Tizen, LG webOS, and Fire TV typically costs $50,000–$150,000 per platform with an agency. This is why "which devices do we launch on?" is a budget question, not just a product question — every screen you add is another build line and another thing to maintain. We cover the device landscape in detail in the OTT client matrix; for the cost model, the rule is simple: count your launch surfaces, because each one is a build line item.

One more build-adjacent recurring cost rides along with it: maintenance, which runs about 15–20% of the initial build cost per year for updates, OS-version compatibility, security patches, and the device-certification treadmill. A $250,000 build implies roughly $37,500–$50,000 a year just to keep the apps working as the platforms beneath them change. Budget it from day one; it does not go away.

The recurring run: the four lines that repeat every month

Now the bill that arrives monthly. It has four meaningful lines — encoding, storage, delivery, and content protection — plus the ordinary application-server and analytics costs every web product carries. We will walk them from cheapest to most expensive, because the order itself is the lesson: the line everyone worries about (encoding) is small, and the line people forget (delivery) is the one that sets your margin.

Encoding: a one-time cost per title, and it is modest

Before content can stream, it has to be converted into the set of quality versions a player switches between — the encoding ladder (the rungs of resolution-and-bitrate the player climbs up and down as the network changes). We explain the ladder itself in the encoding ladder explained; here we only need its price.

Cloud transcoding is billed per output minute — per minute of each rendition produced, not per minute of source. AWS Elemental MediaConvert, a representative cloud encoder, charges about $0.015 per minute for standard-definition/HD output on its Basic tier (AVC), with 4K and premium codecs (HEVC, AV1) carrying multipliers (4K runs roughly $0.05+ per minute, and a 4K HEVC encode can carry a 10× multiplier on the Professional tier). Pricing dated 2026; re-verify, because encoder pricing changes.

Here is the key property: encoding is a one-time cost per title. You encode a film once and serve it a million times; you only re-encode when you add new content or change your ladder. So even a large catalog costs little to encode relative to the monthly delivery bill, and the cost does not recur with viewership. We will put a number on it in the worked example, and it will be one of the smallest figures in the whole model.

Storage: cheap, and it scales with catalog, not audience

Once encoded, the files sit in object storage waiting to be served. Cloud object storage is inexpensive: Amazon S3 Standard is about $0.023 per gigabyte per month for the first 50 TB (us-east-1, 2026), dropping slightly at higher volumes. Storage scales with catalog size and ladder depth — how many hours you hold and how many renditions each — and not at all with how many people watch. A big catalog with few viewers has a high storage bill and a low delivery bill; a small catalog with a huge audience is the opposite. Storage is almost never the line that decides your economics, but it is the one that quietly grows as your library does.

Delivery (egress): the line that decides whether you have a business

This is the one. Egress is the fee a content delivery network charges to send bytes out of its edge servers to viewers. A content delivery network (CDN) is the layer of servers spread around the world that keep copies of your video close to viewers so they are not all hitting one origin server; we explain how it works in how a CDN delivers video. For the cost model, the thing to internalise is that egress is the dominant recurring cost of any streaming platform at scale, and it scales with the one variable nothing else does: total bytes delivered, which is watch-time × bitrate × audience.

Egress is tiered, not a flat per-gigabyte price, and the tiers matter. As an anchor, Amazon CloudFront's US/Canada pay-as-you-go rates (pulled from AWS 2026-06-08) are: the first 1 TB per month free, the next 9 TB at $0.085/GB, the next 40 TB at $0.080/GB, the next 100 TB at $0.060/GB, the next 350 TB at $0.040/GB, and the next ~524 TB at $0.030/GB, falling toward $0.020/GB at petabyte scale. Two more facts change the bill materially: data fetched from an AWS origin into CloudFront is free (you pay only for delivery to viewers), and a commitment discount — the CloudFront Security Savings Bundle — cuts up to 30% off in exchange for a one-year minimum-spend commit, with deeper custom discounts for commits of 10 TB/month or more.

A note that saves teams from a nasty surprise: many CDNs and transit providers bill bandwidth at the 95th percentile of usage rather than total transfer, which means a few spiky hours (a live premiere) can set the price for the whole month. The pricing model matters as much as the per-gigabyte number. State the model and the date; never quote a single price as if it were universal. We dig into commits, the 95th percentile, and the offload ratio in CDN cost engineering.

Content protection (DRM): a per-viewer or per-licence fee

If you license premium content, studios require digital rights management (DRM) — the system that keeps the decrypted video and its keys from being copied. We cover what it is and why in why DRM exists and the modern multi-vendor pattern in multi-DRM, one workflow. For the cost model, DRM is a recurring fee charged either per licence issued or per monthly active user. Representative 2026 pricing: managed multi-DRM services start around $300/month for ~100,000 licences, or tiered per-user models such as $299 for the first 1,000 monthly active users plus roughly $0.04–$0.06 per additional user. Self-hosting a multi-DRM stack runs $10,000–$50,000+ to set up and $500–$5,000/month to operate — rarely worth it until you are very large. DRM is a real line but usually a single-digit percentage of the egress bill.

The worked example: a 2,000-hour SVOD platform at 50,000 viewers

Numbers make the model concrete, so let us build one platform end to end and show every step of the arithmetic. The assumptions are deliberately middle-of-the-road; change them in the companion spreadsheet to match your own plan.

The platform. A subscription video-on-demand (SVOD) service. Catalog of 2,000 hours. Audience of 50,000 monthly active viewers, each watching 10 hours a month. A six-rung encoding ladder whose renditions sum to about 12 Mbps of stored bitrate, and an average delivered bitrate of 3 Mbps (most viewing happens on the middle rungs, not the top one). Delivery on a CloudFront-class CDN at US rates. Subscription price (ARPU) of $8/month.

Step 1 — one-time encode. Output minutes = source minutes × ladder rungs.

source minutes   = 2,000 hr × 60          = 120,000 min
output minutes   = 120,000 × 6 renditions  = 720,000 min
encode cost      = 720,000 × $0.015/min    = $10,800  (one time)

The entire catalog encodes for about $10,800, once. Add a 4K HEVC top rung and it climbs, but it is still a one-time figure measured in five digits — trivial next to the monthly delivery bill.

Step 2 — monthly storage. Stored bytes = hours × seconds × aggregate bitrate.

stored data = 2,000 hr × 3,600 s × 12 Mbit/s ÷ 8 = 10,800,000 MB ≈ 10.8 TB
+ mezzanine masters (~4 TB)                        ≈ 15 TB total
storage cost = 15,000 GB × $0.023/GB-month         ≈ $345 / month

Holding the whole catalog costs about $345 a month. Storage is real but small.

Step 3 — monthly delivery (egress), the big one. First find total bytes delivered, then walk the CDN tiers.

data per viewer = 10 hr × 3,600 s × 3 Mbit/s ÷ 8 = 13,500 MB = 13.5 GB
total delivered = 50,000 viewers × 13.5 GB        = 675,000 GB = 675 TB / month

Now apply the tiered CloudFront US rates, tier by tier:

first   1 TB  free                         = $0
next    9 TB  × $0.085/GB (9,000 GB)        = $765
next   40 TB  × $0.080/GB (40,000 GB)       = $3,200
next  100 TB  × $0.060/GB (100,000 GB)      = $6,000
next  350 TB  × $0.040/GB (350,000 GB)      = $14,000
remaining 175 TB × $0.030/GB (175,000 GB)   = $5,250
-----------------------------------------------------
egress, list price                          ≈ $29,215 / month
with a 30% savings-bundle commit            ≈ $20,450 / month

Delivery is roughly $29,000 a month at list, or about $20,000 with a commit. This single line is larger than everything else in the model combined.

Step 4 — monthly DRM. Using a tiered per-user model:

$299 (first 1,000 MAU)
+  9,000 users × $0.06   = $540      (1,001–10,000)
+ 40,000 users × $0.04   = $1,600    (10,001+)
-------------------------------------------------
DRM ≈ $2,439 / month

Step 5 — add it up. Encoding is one-time, so it does not appear in the monthly run; amortised over a year it adds ~$900/month. Application servers, database, and analytics for a platform this size run on the order of $2,000–$4,000/month; call it $3,000.

egress (list)        ≈ $29,215
DRM                  ≈ $2,439
storage              ≈ $345
app/db/analytics     ≈ $3,000
encode (amortised)   ≈ $900
-------------------------------------------------
total recurring      ≈ $35,900 / month  (≈ $26,000 with a CDN commit)

Step 6 — the number that matters: cost per viewer.

cost per viewer = $35,900 ÷ 50,000 = $0.72 / viewer / month
ARPU            = $8.00 / viewer / month
gross margin    = ($8.00 − $0.72) ÷ $8.00 ≈ 91%

At these assumptions the unit economics are healthy: each viewer costs about 72 cents a month to serve against $8 of revenue. But notice what moves that number. Double the average bitrate (4K-heavy viewing) and egress roughly doubles, pushing cost-per-viewer toward $1.30. Drop the subscription to $4 and the same cost line halves your margin. The model is not "is it profitable?" in the abstract — it is "does your price cover your delivery cost at your audience's real bitrate?"

Egress cost ramp: monthly delivery bill rising with total bytes delivered across the tiered CDN rates, with the commit-discount lever shown as a lower curve. Figure 2. The egress ramp. The monthly delivery bill climbs with bytes delivered (watch-time × bitrate × audience); a commit discount shifts the whole curve down. Catalog size does not appear on this axis.

What actually drives the bill: the four levers

The worked example exposes the levers worth pulling. Each one moves the dominant line — delivery — far more than any saving on the small lines.

The first lever is codec efficiency. A more efficient codec delivers the same picture at a lower bitrate, and because egress is bytes, lower bitrate is a lower bill. Moving popular content from H.264 to HEVC or AV1 can cut delivered bitrate 30–50% for equal quality, which flows straight through to egress. The trade-off is encode cost and device support; we frame that product decision in codec strategy for OTT and the underlying codec mechanics live in our Video Encoding section. Spend a little more encoding (one-time) to spend a lot less delivering (every month).

The second lever is the cache-hit ratio — the share of viewer requests the CDN serves from its own edge cache instead of fetching from your origin. A high cache-hit ratio is normal for VOD because popular titles are requested over and over, and it keeps the origin and its bandwidth cheap. A badly designed cache key (covered in edge caching and cache keys) destroys the hit ratio and inflates both origin cost and latency.

The third lever is commit pricing. Once your traffic is predictable, a one-year commitment (the CloudFront Savings Bundle or an equivalent) buys up to 30% off, and multi-CDN negotiation buys more. The catch is that commits are a bet on volume: commit too high and you pay for bytes you did not deliver. Match the commit to your floor, not your hopeful peak.

The fourth lever is per-title encoding — tuning the ladder to each piece of content instead of applying one fixed ladder to everything. A fixed ladder wastes bitrate (and therefore egress) on simple content that does not need the top rungs, while per-title encoding cuts storage and delivery for measurable savings. We quantify it in per-title encoding economics.

Build vs buy vs assemble: where the money goes

There are three ways to get a platform, and they trade money against control in opposite directions.

Buy an off-the-shelf OTT SaaS (Brightcove, JW Player, Vimeo OTT, Muvi). Lowest build cost and fastest launch, but you rent the platform — recurring fees scale with usage, you inherit the vendor's CDN and DRM markups, and you have limited control over architecture and margin. Good for testing a market; expensive at scale because someone else's margin is baked into your egress.

Assemble from cloud primitives (AWS MediaConvert/MediaLive + S3 + CloudFront + a multi-DRM service). Medium build cost, full control of the architecture, and you pay cloud list prices (with commit discounts available). This is where most serious custom platforms land, and it is the model the worked example above prices.

Build fully custom, including bespoke back-end services and possibly self-hosted encoding or DRM. Highest build cost and only worth it at large scale or with unusual requirements, where shaving the recurring bill repays the engineering.

The decision is not "which is cheapest" but "at what scale does control pay for itself". We walk the full decision in OTT platform build-vs-buy; the cost-model takeaway is that SaaS minimises build cost and maximises recurring cost, while assemble/build does the reverse.

Approach One-time build Recurring run Control of architecture & margin Time to launch
Buy (OTT SaaS) Lowest ($) Highest — vendor markups on egress/DRM Low Weeks–months
Assemble (cloud primitives) Medium ($$) Cloud list price, commit-discountable High Months
Build (fully custom) Highest ($$$) Lowest at large scale Full Many months

Table 1. The three ways to get an OTT platform. The column that decides the business is "recurring run", not "one-time build".

A common mistake: budgeting from the build quote

The error we see most often is a budget built entirely around the one-time build number, with the recurring run treated as a rounding error or a "we'll figure it out later". A team raises money against a $200,000 build, launches, finds an audience — and then the egress bill arrives and nobody modelled it. Because delivery scales with watch-time and audience, the run cost is small in beta and frightening at scale, exactly when the company can least afford a surprise.

The second face of the same mistake is quoting CDN cost as a single per-gigabyte price. Egress is tiered, commit-dependent, and sometimes billed at the 95th percentile; "we'll pay about $0.08 a gig" is wrong in three different directions at once. Model the tiers, decide whether to commit, and know your billing model before you sign.

The third face is confusing catalog size with cost. A bigger catalog raises storage (cheap) and encoding (one-time), but it does not raise delivery — only watching does. A platform with 10,000 hours and 1,000 viewers is cheap to run; a platform with 200 hours and 1,000,000 viewers is expensive. Budget against viewers and their bitrate, not against library size.

Where Fora Soft fits in

The hardest part of an OTT budget is not the build — it is forecasting the recurring run and engineering the platform so that delivery cost stays under control as the audience grows from a thousand viewers to a million. Fora Soft has built video streaming, OTT/Internet TV, e-learning, telemedicine, and surveillance software since 2005, across 625+ shipped projects for 400+ clients, and that work is squarely about scaling delivery economically: tuning the encoding ladder, raising cache-hit ratios, designing multi-CDN delivery, and integrating DRM without paying a SaaS markup on every byte. When a media company needs a custom platform whose unit economics survive contact with a real audience, that scale-and-cost engineering is the capability we bring. The model in this article is the same one we use to scope a build.

What to read next

Call to action

References

  1. Amazon CloudFront pay-as-you-go pricing — Amazon Web Services. Regional Data Transfer Out to Internet (per GB), US/Canada tiers; AWS-origin fetches free; Savings Bundle up to 30%. Page updated 2026-06-08. Tier 4 (first-party vendor). https://aws.amazon.com/cloudfront/pricing/pay-as-you-go/ (accessed 2026-06-15)
  2. Amazon CloudFront pricing (flat-rate and free tier) — Amazon Web Services. Free tier (1 TB/month, 10M requests); flat-rate plans. Updated 2026-06-08. Tier 4. https://aws.amazon.com/cloudfront/pricing/ (accessed 2026-06-15)
  3. AWS Elemental MediaConvert pricing — Amazon Web Services. Per-output-minute transcode pricing, Basic vs Professional tiers, codec multipliers, reserved/volume discounts. Tier 4. https://aws.amazon.com/mediaconvert/pricing/ (accessed 2026-06-15)
  4. Amazon S3 pricing — S3 Standard storage — Amazon Web Services. ~$0.023/GB-month first 50 TB (us-east-1). Tier 4. https://aws.amazon.com/s3/pricing/ (accessed 2026-06-15)
  5. RFC 8216 — HTTP Live Streaming (HLS) — IETF. The HLS manifest/segment format produced by the packager; the delivery format whose bytes incur egress. Tier 1 (official standard). https://www.rfc-editor.org/rfc/rfc8216 (accessed 2026-06-15)
  6. ISO/IEC 23009-1 — Dynamic Adaptive Streaming over HTTP (MPEG-DASH) — ISO/IEC. The DASH manifest/segment format; the second delivery format a platform serves. Tier 1. https://www.iso.org/standard/83314.html (accessed 2026-06-15)
  7. ISO/IEC 23000-19 — Common Media Application Format (CMAF) — ISO/IEC. One set of fragmented-MP4 segments serving both HLS and DASH; relevant to storage and ladder cost. Tier 1. https://www.iso.org/standard/85623.html (accessed 2026-06-15)
  8. ISO/IEC 23001-7 — Common Encryption (CENC) — ISO/IEC. The cenc/cbcs encryption schemes underlying the multi-DRM step priced here. Tier 1. https://www.iso.org/standard/84637.html (accessed 2026-06-15)
  9. DoveRunner multi-DRM pricing — DoveRunner. Tiered per-MAU multi-DRM pricing ($299 first 1,000 MAU + per-user tiers). Tier 4. https://doverunner.com/pricing/ (accessed 2026-06-15)
  10. EZDRM service pricing — EZDRM. Per-licence/per-stream multi-DRM pricing reference. Tier 4. https://www.ezdrm.com/service-pricing (accessed 2026-06-15)
  11. Custom OTT app development cost (2026 market survey) — Appinventiv. Build-cost ranges by scope; per-platform native-app costs; maintenance 15–20%/yr. Tier 7 (SEO/market content) — orientation only; flagged as non-authoritative. https://appinventiv.com/blog/ott-app-development-cost/ (accessed 2026-06-15)

Source note (per §4.3.2): build-cost ranges (reference 11) come from a tier-7 market survey and are used only as orientation; they are flagged in the text as ranges, not quotes. All recurring-cost figures (egress, storage, transcode, DRM) trace to first-party vendor pricing pages (tier 4) dated 2026, and all delivery-format claims trace to tier-1 standards (refs 5–8). No lower-tier source overrode a standard.