What shipping 44 apps in three months actually taught us

2026-07-31 · Written from our own App Store work

Every app in our catalogue was released or updated within a three-month window. That pace taught us things, but the most useful lesson was about what it does not fix.

What velocity genuinely buys

Three things, all real:

Compounding infrastructure. The first app costs you the app plus everything around it — privacy policy, support page, screenshot pipeline, release checklist, analytics. By the tenth, that scaffolding is written and the marginal cost of an app collapses. This is the actual reason a small studio can maintain a wide catalogue.

Faster feedback about ideas. You learn more from one shipped app than from ten discussions about which to build. Shipping resolves arguments that planning cannot.

Review fluency. After enough submissions you know which metadata triggers questions, how long a review takes at different times of year, and what a rejection actually means. That knowledge only comes from volume.

What it does not buy

Downloads, and definitely not revenue.

This is the uncomfortable part. Adding an app adds a surface, but a surface nobody finds produces nothing. The distribution problem is the same on app forty-four as it was on app one, and solving it forty-four times over is not the same as solving it once.

Our honest conclusion after that quarter: the number of apps was never the constraint. Pricing and in-app purchase design were, and no amount of shipping compensates for a catalogue that does not ask for money clearly.

The maintenance debt nobody mentions

Each app is a permanent obligation, not a finished product. Every iOS release, every deprecated API, every store policy change applies to all of them. Forty-four apps means forty-four sets of screenshots to regenerate when device sizes change.

Two practices make this survivable, and both have to be decided early:

  • Shared code, actually shared. If a fix has to be applied by hand in forty places, it will be applied in five and forgotten in thirty-five.
  • Generated store assets. Screenshots and metadata built by a script, not by hand. The first time Apple adds a device size, this decision pays for itself entirely.

What we would do differently

Fewer apps, monetised properly, each given a real launch. The pace was worth having — it built the machinery and taught us the store. But we would trade breadth for depth on the next ten, because breadth is the part that turned out to be cheap.

0%

Who writes this: BIR is an independent software studio with 44 apps on the App Store, built and shipped in-house. These notes come from problems we hit ourselves — the numbers are ours and you can check the reasoning against your own account.