TuneClub logged 48,100 minutes of tracked practice and now earns recurring revenue

The situation

Learning traditional Irish music was not short of tools. That was the problem. A learner kept tune recordings in one place, a slowed-down practice track in another, a tutor's notes somewhere else, and the thing they were actually working toward, a session or a workshop, in a WhatsApp thread. Nothing joined up.

And beneath the fragmentation sat the problem every music teacher knows: progress becomes invisible. A learner practises for weeks, nobody can see it happening, and they quietly disappear. Music schools don't lose students when lessons get worse. They lose students when progress becomes invisible.

For Gabe Moynagh, who runs the platform and had the cause long before he had the product, that fragmentation had a commercial edge to it too. With no single platform there was no clean way to see what the thing earned. No recurring revenue. Bookkeeping by hand. And for creators, the people who make the content the whole product depends on, no way to sell anything without it becoming somebody's admin job.

He came to us with a design from a previous attempt and a clear idea of the outcome. The design was the first thing we changed.

What followed was not a 12-week build, and an earlier version of this page said it was. TuneClub has run roughly 48 weeks of product work across two-plus years, through V1, V1.5, V2, and V2.5. The first release took 12 to 16 weeks and was deliberately modest: enough of a product to tell us whether people would actually practice. They did. That answer is what paid for V2.

The problems worth reporting

• Creator-defined pricing, inside app stores that want to approve every SKU

  This is the hardest problem on the project and the least visible from outside. TuneClub is creator-led. A creator should be able to launch an offering, name their own tier, and price it, without RaftLabs deploying anything and without Apple reviewing anything. App stores are built on the opposite assumption: products are defined up front and reviewed.

  We had a hard launch date, so building a billing layer directly on the store APIs was off the table. We chose RevenueCat, and then used it in a way it is not usually used: as a durable transaction store and gateway, with its own entitlement system deliberately left out. Entitlements are ours, modelled around creator-defined tiers that map onto a fixed set of internally managed SKUs. A creator names and configures their offering inside the platform; the store only ever sees the SKUs it already approved.

  Worth saying plainly: the delivery lead argued against RevenueCat at first, having never seen it used this way. The call came from our side of the table and it was the right one. Building on raw store APIs would have been a time sinkhole, and the stores have historically changed those APIs without asking.

• Building for flexibility we could not yet describe

  The recurring tension across two years was immediate rigidity against eventual flexibility. There was one creator at launch, first-party, and an eventual ambition of many. Every modelling decision had a now-answer and a later-answer, and they often contradicted each other.

  V2 is where that bill came due. Assumptions baked into V1 became actively unhelpful in V2, and the backend absorbed most of the damage. TuneClub had the longest brainstorming phase of anything we have built, roughly seven to nine weeks before V2 implementation started, precisely because we were trying to settle those contradictions on paper rather than in migrations.

  Asked what he would change, the delivery lead was specific: stop building hard database models around entities that turn out to be containers. Build a labellable container that arbitrary things can be stashed into, and resolve the meaning later. That is the retrospective we would hand to anyone starting a creator platform where the catalogue shape is genuinely unknown.

• Audio practice tools that stay responsive on an average phone

  Pitch shifting, tempo control, looping, and in-app recording are heavier than video playback and they run on whatever phone the learner owns. A glitch mid-practice does not read as a bug to a musician, it reads as the app breaking their concentration.

  The Flutter app carries a media abstraction layer so the practice tools sit above platform-specific playback rather than inside it, which is what let the underlying audio implementation change without the feature layer changing with it. Video delivery went to Mux for adaptive streaming, thumbnails, and captions, so engineering time went into the practice tools rather than into media infrastructure.

  The product started life as a prototype with a file picker and a couple of playback controls. Nobody on the team predicted how far the tooling would eventually go, and that under-estimate is worth naming.

• Two features that failed feasibility and were not built

  The client arrived with a recommended partner for AI practice feedback: a third-party music AI service that would listen to a learner's recording and assess it. Early feasibility work showed it could not deliver usable results reliably enough to ship behind a paid product. We did not build it. An alternative approach is being planned now.

  The second was low-latency group jamming, musicians practising a piece together over the network in real time. We ran the feasibility study. On a good WiFi backhaul and an average phone, round-trip latency lands around 180 to 200ms. That is fine for a meeting and useless for playing in time with someone. The physics did not care how much we wanted it, so it is not in the product.

  Both were real ambitions, both had client enthusiasm behind them, and both were killed by evidence rather than by budget. We would rather publish that than a feature list of things that worked.

1. A creator-led subscription economy the stores will actually approve

   Tiered subscriptions, with creator-defined names and offerings mapped onto a fixed, pre-approved set of internally managed SKUs. RevenueCat handles the transaction and the store relationship; entitlement logic is ours. The practical effect is that a new creator offering goes live the same day rather than waiting on an App Store review, which is the difference between a creator economy and a catalogue we maintain on their behalf.

   

2. Practice tools built into the lesson, not beside it

   Metronome, pitch and speed control, track clipping, personal notes, and in-app recording all sit inside playback. A learner slows a difficult passage, transposes it, loops eight bars, and records the result without leaving the track. Notes and recordings stay attached to the track that produced them, which is what makes practice history mean anything later.

   

3. Submission and creator review, in one loop

   Learners record and submit; creators review in the web portal, answer the custom feedback questions configured for that pathway, and approve or ask for another take. Creators are musicians and community leaders, not people who wanted a second admin job, so the review screen was built to be fast rather than thorough-looking. The learner sees the decision in the mobile app immediately.

   

4. A design rebuilt for the age band that actually shows up

   The concept we inherited was extremely information dense. It took several rounds with our designers to get it to something a wide age band could use without learning the ropes first, and we are still tweaking it. This was the first thing we pushed back on and it was not a small piece of work. Community channels, announcements, and per-category notification controls live inside the same simplified shell.

   

How it runs

Flutter

The learner app needed native-level audio behaviour, pitch shifting, tempo control, and real-time recording, on both stores from one codebase and one small team. Flutter compiles to native and held up for the practice tooling. The media handling sits behind an abstraction layer so the underlying audio implementation can change without the feature layer moving with it, which it has.

RevenueCat

Used as a durable transaction store and store gateway, with its entitlement system deliberately unused, because entitlements had to follow creator-defined tiers rather than a fixed product list. We had a hard launch date and building on raw store APIs would have been a sinkhole, particularly given how often those APIs have changed. The delivery lead argued against this choice initially and now names it the decision he is most glad we made.

Hasura GraphQL

The creator portal had to show new submissions and feedback state as they arrived, which GraphQL subscriptions give without polling. Beyond that, this is a stack we have been refining across projects for years: the visibility, built-in tooling, and reporting layers are what make a two-year product debuggable by whoever is on it this quarter.

AWS Lambda

Submission processing, notification delivery, and media event handling run serverless, so submission spikes around an event deadline do not require capacity provisioned in advance for a platform whose baseline load is modest.