2
1 Comment

Why I built an app builder that gives away its source code

After two decades in radio, I kept watching the same thing happen: a station pays a hosted app builder for years, then the platform raises prices, or shuts down, or the station just wants to leave — and the app dies with the subscription. All that audience, gone. The listing, the reviews, the installs: rented, never owned.

So I built nerapo the other way around. You configure everything in a web dashboard — stations, podcasts, audiobooks, branding, push, paywall — and it generates real native projects: SwiftUI for iOS, Kotlin + Jetpack Compose for Android. You download the ZIPs, sign them, publish under your own Apple and Google accounts. Your bundle ID, your name on the listing. Nothing of mine anywhere a reviewer or a listener can see.

The part that took longest to get right: after that first publish, almost everything still updates live from the dashboard — content, colors, tabs, push, paywall flags — no rebuild, no store re-review. The list of things that DO need a rebuild fits in one short FAQ answer.

Deliberate constraints that shaped it: no webview (the apps do CarPlay, background audio, widgets, offline — things a wrapper can't), no analytics SDKs at all in the generated apps, and no stream hosting — you bring your own Shoutcast/Icecast/HLS URL, which means no per-listener fees. 10 listeners or 100,000, same flat price.

It's live, the demo app in both stores is the actual product, and the sandbox needs no signup. Happy to answer anything about the build or the model — especially from anyone who's fought hosted builders before.

posted toAvatar for product nerapo
nerapo
  1. 1

    The interesting part here is shifting ownership from a subscription dependency to an asset the customer controls.

    Curious whether broadcasters care more about owning the source code, avoiding vendor lock-in, or having the flexibility to customize the app long term?