Why We Don't Price by Monthly Active Users

An OTA platform becomes more valuable as an application grows. A larger audience makes a fast fix more consequential, turns a careful rollout into a more useful risk-control tool, and increases the value of knowing exactly which release is running in production.

That raises an interesting pricing question: should user growth itself increase the cost of the OTA platform?

Monthly Active Users, usually shortened to MAUs, provide a familiar way to connect a software bill to product scale. The metric is broadly understood and useful when workload grows mainly because more distinct people use an application.

OTA delivery has a less direct relationship with audience size. A release system stores artifacts, evaluates update requests, transfers bundles and assets, prepares delivery optimizations, retains operational history, and helps teams understand or recover from releases. User count influences some of that work, but it does not describe all of it—and often does not describe the most important constraints by itself.

Bundle Drop therefore does not use MAUs as its pricing unit. That is not a claim that MAU pricing is universally wrong. It is a decision about what our pricing should represent and which behavior it should encourage.

What actually costs money in an OTA platform?

An OTA system is not a single file download behind a dashboard. Its operating costs come from several resources with different scaling patterns.

Object storage and retention

Each release can include a JavaScript bundle, assets, source maps, and delivery artifacts. Those objects occupy storage for as long as they are retained. Previous releases provide known-good versions for rollback and evidence for incident review.

Storage grows with artifact size, release frequency, the number of applications and runtime lines, and retention policy. It does not necessarily grow when an existing application gains another active user. A million installations referencing one retained bundle do not create a million stored copies of that bundle.

Keeping every build forever costs more than expiring routine releases while preserving production history. Bundle Drop makes production-channel retention an explicit lifecycle decision, described in Production Channels, because stored history is a real resource.

Bandwidth and update traffic

Delivering an update consumes network bandwidth. That cost depends on the size of the delivered content and the number of devices that actually request and download it. The relationship to MAUs is real in some cases, but it is not one-to-one.

An active user may receive no update during a month. Another installation may download several releases while a team iterates quickly. A large application might ship one small fix; a smaller application might publish many asset-heavy releases. Devices can also skip intermediate releases or remain offline throughout a rollout.

Delivery method matters too. A patch can reduce transferred data when the device has a suitable starting state, while a complete bundle remains necessary as a reliable fallback. The engineering tradeoff is covered in Why Bundle Drop Combines Patch Delivery with Full-Bundle Reliability. The relevant point for pricing is that transfer cost reflects actual artifacts and delivery behavior, not just the number of distinct people who opened the app.

Patch preparation and compute

Optimized delivery requires compute. The system may need to prepare patch artifacts, validate release inputs, process assets, and perform other work when a bundle is uploaded. Release selection also consumes compute when installations check for compatible updates.

These workloads scale differently. Preparation work often follows publish activity and artifact characteristics. Resolve traffic follows application behavior, update policy, and fleet size. A single audience count can hide those differences.

Metadata and observability

OTA reliability depends on metadata: projects, channels, runtime versions, releases, rollout state, targeting rules, installation state, and audit context. Teams also need enough observability to connect a production issue to the exact bundle involved.

The cost of retaining and querying this information depends on the product model. Detailed per-install history has a different profile from aggregate events, and long audit retention differs from a short operational window. Audience size can matter, but it remains one input among several.

Support and operational responsibility

Managed infrastructure includes human work. Release incidents need diagnosis, integrations need support, and storage, delivery, monitoring, and security controls need maintenance. A complex native integration may require more attention than a much larger conventional application.

Reasonable providers can therefore arrive at different pricing models. Their infrastructure, commitments, and best predictors of cost differ. No meter captures every OTA workload perfectly.

What MAUs represent

A Monthly Active User is usually a distinct user who meets a product's definition of activity during a calendar month. The rules vary: a provider might count accounts, anonymous installations, devices, or users who trigger a particular event. That matters when one person uses multiple devices or many users are anonymous.

MAUs are useful when value and workload closely follow user activity. Analytics products are a clear example: more active users generally produce more events, stored behavioral data, and query volume. The unit can approximate both customer value and provider workload.

For OTA infrastructure, MAUs answer a different question: how many distinct users were active? They do not directly answer:

• how many releases the team published;
• how large those releases were;
• how much retained storage they occupy;
• how many devices checked for an update;
• how many bytes devices downloaded;
• how many runtime lines or release channels the team operates;
• how much rollout history and operational support the release process requires.

The metrics can correlate. A larger active audience often produces more update checks and can produce more delivery traffic. But the correlation depends on application behavior, update cadence, client policy, cache behavior, and the size of each change.

Consider two applications with the same MAU count. One publishes a compact update every few weeks; the other publishes large asset changes across several runtime versions. Their audience measure is equal, but their operational profiles differ.

The inverse is also possible. A stable application can gain a large audience without publishing anything new that month. The OTA platform becomes more important because the consequence of a future release is larger, but much of the artifact-processing workload has not changed merely because more people opened the app.

MAU pricing smooths those differences into a predictable business metric. That simplicity is a strength. Our concern is the incentive it can create for OTA: teams may begin to see healthy adoption as a reason to restrict release tooling even when the workflow has barely changed.

Bundle Drop's philosophy

Bundle Drop prices around capacities that more closely reflect operating the release system rather than charging for each active member of an application's audience. The current public pricing surface identifies shared OTA storage and organizational capacity explicitly; the pricing page remains the source for current limits because those details can change.

This choice comes from four principles.

User growth should not feel like a pricing penalty

An engineering team should be pleased when an application gains users. The OTA bill should not turn that outcome into an immediate release-management concern simply because another person opened the app.

The platform still handles more traffic as a fleet grows, and no infrastructure has infinite capacity. Our position is narrower: MAU count is not the unit we want teams watching when they evaluate affordability. We prefer resource and service capacity to a meter attached to audience growth.

Teams should be comfortable shipping focused improvements

OTA tooling lets teams deliver compatible JavaScript and asset changes without another store binary. Pricing can quietly shape how often they use it.

If every update is viewed mainly through audience size, teams may combine unrelated changes, delay small fixes, or avoid a careful rollout because distribution feels financially risky. No model makes those behaviors inevitable, but pricing should not encourage them.

The relevant questions should stay technical: Is the change runtime-compatible? Was the exact artifact validated? Should it move through beta first? Is rollback ready? The answers should not depend on an audience threshold crossed last week.

Storage and operational capacity are meaningful constraints

Retained OTA artifacts consume a measurable resource. Projects, channels, team access, and release operations create understandable system capacity. These units are not perfect representations of cost either, but they are closer to decisions the engineering team controls.

A team can remove obsolete artifacts, choose retention, separate applications into projects, and design its release workflow. Those are release-management choices. Becoming popular is not.

When storage approaches a limit, the team can inspect what is retained and why. A MAU threshold says more users were active but offers no comparable operational action.

Pricing should remain predictable

Predictability is not the same as never changing. A team that adds applications, retains more release history, expands its organization, or requires more operational capacity should expect its needs to evolve.

Engineers can connect those changes to the release system they operate. They can forecast keeping more artifacts or adding projects without estimating how many users will open the app in a billing month.

Audience forecasts are uncertain. A successful launch, seasonal event, or return of dormant users should not trigger an emergency review of whether the team can publish a production fix.

The tradeoffs are real

No pricing model maps perfectly onto cost, value, and customer expectations at the same time. Each chooses an approximation and creates incentives around it.

MAU-based pricing is familiar and can align price with the reach or business value of a product. It can be straightforward for organizations that already track active users carefully. Depending on the platform, it may also approximate resolve traffic, metadata volume, and support expectations reasonably well. Its weakness is that audience activity does not always match release workload, and teams may have to define or reconcile user identity across devices.

Bandwidth pricing tracks transferred data directly. That makes a major infrastructure cost visible and rewards smaller updates. It can also make a production rollout hard to forecast: transfer volume changes with release size, fleet state, retry behavior, and network conditions. Teams may become hesitant to ship or to use a full-bundle fallback when reliability requires it.

Storage pricing connects the bill to retained artifacts and is comparatively easy to inspect. It encourages deliberate retention and cleanup. But storage alone does not capture update checks, bandwidth, compute, support, or operational complexity. A small set of heavily downloaded bundles can use little storage while generating substantial delivery work.

Seat pricing reflects the number of people collaborating in the release system. It is predictable and familiar for internal tools. It can, however, discourage broad operational ownership by making teams limit access for QA, support, or incident responders. Seats also say little about fleet size or delivery volume.

Combined usage models can represent costs more accurately by charging across storage, bandwidth, seats, requests, or compute. Their tradeoff is cognitive load. A technically precise invoice can still be a poor product experience if customers need a capacity model to predict every release.

Bundle Drop's current approach is also a tradeoff. Resource-oriented capacity is only an approximation of the complete cost to run the service. Some applications with similar storage needs will produce different traffic and support workloads. Choosing not to meter MAUs means Bundle Drop accepts more variation behind the same visible capacity.

We consider that variation worthwhile because the resulting incentive matches the product we want to build. Teams can evaluate storage and operational capacity without treating every new application user as another unit of OTA liability. If that balance needs to evolve, it should do so transparently and around understandable operating constraints.

Pricing is part of the engineering interface

Pricing is not separate from system design. It tells customers which behavior the provider expects them to monitor, optimize, and sometimes avoid.

Bundle Drop does not price by Monthly Active Users because audience size is an incomplete description of OTA workload and because we do not want healthy user growth to become a reason to second-guess release safety. We prefer capacities tied more closely to retained artifacts and the operational shape of the release system, while acknowledging that those units are approximations too.

MAU, bandwidth, storage, seat, and combined models can all be sensible choices for different businesses. The important question is whether the chosen meter reflects the service well enough and produces behavior both the provider and its customers can live with.

For Bundle Drop, the desired behavior is straightforward: validate exact artifacts, publish focused fixes, use progressive rollout when risk calls for it, retain enough history to recover, and let application growth remain a good outcome.

Pricing should encourage teams to improve their apps rather than make them hesitant to ship updates.