Why we moved to per-app pricing
Flat subscriptions sound simple, but they make small projects subsidize big ones. Here's why we switched to $5 per app.
When we launched CodeHost, we charged one flat subscription: pay a monthly fee, install as many apps as you want. It sounded generous. It sounded simple. Over time, we realized it was quietly unfair.
The problem with a flat subscription is who pays for it. Most accounts run two or three small apps. A handful run twenty heavy ones. Under flat pricing, the person running a single low-traffic blog pays exactly the same as the person running a cluster of databases. The small user subsidizes the big one.
The entry-price problem
Flat pricing also has a floor. If your cheapest plan is $10 or $25 a month, someone who just wants to run one small app — a status page, a personal wiki — has to pay for capacity they'll never touch. We were turning away the simplest, most common use case: I want to run one app, cheaply.
We looked at the data. The median CodeHost app uses a fraction of a vCPU and sits idle most of the day. Charging that app a full subscription made no sense. It should cost a few dollars — because that's roughly what it costs us.
Pricing should track what you actually run — not a tier you were forced to pick on day one.
How per-app pricing works
So we rebuilt it. Every app you deploy has a size — Small, Medium, or Large — priced at $5, $20, or $50 a month. Your bill is simply the sum of the apps you're running. One small app is $5. Ten small apps is $50. Resize an app and the price moves with it, prorated.
This is more honest in both directions. Small projects finally have a real entry point. Heavy workloads pay for the resources they consume instead of being subsidized. Nobody picks a plan on day one and hopes they guessed right.
What changed
Since switching, signups from single-app users climbed sharply — people who would never have paid for a subscription happily pay $5 for one app. And power users tell us the per-app bill makes cost easier to reason about: every line item is an app they can point to.
If you're pricing a developer platform, ask the uncomfortable question: under your model, who is overpaying so someone else can underpay? If you can name them, your pricing isn't as simple as you think. Ours wasn't. Per-app pricing fixed it.