Floga’s App Pre-Sale: What an Existing Audience Can Validate—and What It Cannot

A close analysis of Floga's yoga-app pre-sale: how an existing physical-product audience reduced launch risk, what the lifetime offer proved, and the obligations it created.

Yoga-sequencing cards and an existing community connect by a gold thread to a partly built mobile app and a payment token.
The existing audience made the pre-sale possible; the payment also created an obligation to finish and support the app. Conceptual illustration, not a Floga screenshot.

An audience that has bought one product from you may be willing to fund the next one before it is finished. That can be a powerful launch advantage, but it is also an easy signal to misread. A customer paying for a lifetime offer may be buying your reputation, a discount, or the chance to support your next project. The purchase does not tell you which features they will use for years or whether strangers will subscribe later.

Floga is an unusually clear example. The team behind PlayPauseBe had already sold physical yoga-sequencing cards. They then developed Floga, a mobile app where practitioners and teachers can build and play their own sequences. In a June 2026 founder interview, Umberto Mezzadra reported more than $120,000 from a 24-hour pre-launch lifetime offer in May 2025. He later described approximately 4,000 active users and about $10,000 a month from a mix of subscriptions and annual plans. Those are self-reported figures, and the monthly amount should not be called MRR without separating recognized subscription revenue from annual cash receipts. Source: Mezzadra's Indie Hackers interview.

The part worth studying is the transfer of trust from one format to another. The cards and the app serve a related job: helping someone design and practice a yoga sequence. That made the app easier to explain to an audience that already knew the method. But the lifetime sale also created a continuing obligation to maintain the product. A founder considering a pre-sale needs to model both sides before counting the receipts as success.

Why this was a credible adjacency

PlayPauseBe's original product was deliberately physical and screen free. Moving into an app could have felt like a contradiction. Mezzadra says the team had to explain why digital sequencing was an extension of what customers already valued rather than a reversal of the brand. He also says the company had an established audience before the app launch and prepared emails, video, and landing pages to educate both existing and new buyers. Source: founder interview.

That is more specific than "build an audience first." The audience already had experience with a particular practice. Floga could keep the core job while changing the tools: arranging poses with cards versus building a sequence digitally and playing it back. The current Floga site explicitly describes the relationship between the physical decks and app, while the PlayPauseBe membership page bundles the app with a digital yoga magazine and continued access to the brand's broader teaching material. Those pages are company marketing, but they verify how the offer is positioned today. Sources: Floga's product site and PlayPauseBe's membership page.

Element Physical product App extension Transfer question
Core job Build and explore a yoga sequence Build, save, adjust, and play a sequence Is the same customer trying to complete the same job?
Customer knowledge The buyer understands the deck The buyer may know the brand but not the app What needs demonstration?
Delivery A shipped object Ongoing software and content What continuing promise is being sold?
Economics Inventory, fulfillment, one-time margin Development, support, store or web payments Which costs continue after the first sale?
Retention Repeated use of an owned deck Continued use and paid renewal What makes the app useful after novelty fades?

This comparison is the first screen in an adjacency test. An email list alone is not enough. If the new product solves a different problem for a different buyer, the old audience may provide attention but little demand. Floga had a closer bridge: same practice, related creators, and a clear reason to carry work from cards into an app.

What the pre-sale proved

Mezzadra says the team chose a lifetime deal because the app was not fully developed and he did not want to charge a recurring subscription for something still in progress. The offer ran outside the app stores. That sale supplied capital and a group of committed early users; the team then added subscriptions as the product matured. Source: founder interview.

I would record four narrow findings from that event:

  1. Some existing audience members trusted this team enough to pay before the software was complete.
  2. The proposed app was close enough to the existing yoga-sequencing job to explain and sell.
  3. A limited launch offer could fund continued development.
  4. The buyers created a useful early cohort for product feedback.

It does not establish that the app will retain subscribers at a sustainable rate, that a cold audience would convert similarly, or that one-time customers will be profitable after years of software and content delivery. The reported $120,000 is launch cash, not recurring revenue or net profit. Payment processing, refunds, support, taxes, and future service costs must be accounted for separately. The public interview does not provide a full cohort statement, so an outside analyst cannot calculate lifetime economics from the launch figure.

The difference between cash and validation is particularly important because the offer was time limited and discounted. Scarcity can move interested buyers to act. It can also pull purchases forward from people who might otherwise have bought later. Either way, it changes the composition of the cohort. A founder should compare subsequent product use, complaints, referrals, and renewals rather than treating day-one conversion as proof of durable demand.

The hidden ledger behind a lifetime deal

A lifetime deal converts future access into cash today. For a simple downloadable file, that may be easy to service. For a living app, the promise includes hosting, bug fixes, platform updates, customer support, and sometimes new content. Floga's public terms specify that lifetime access lasts for the operational life of the app, and describe a continuing service with subscriptions as well as limited-time lifetime packages. This is a company-specific contractual statement; it does not define what "lifetime" means everywhere. Source: Floga terms.

Before using a lifetime offer, build a ledger with a cohort, not just a revenue line:

Entry Ask before launch Measure after launch
Cash received What is the net amount after payment fees and expected refunds? Net receipts by cohort
Delivery promise Which features and updates are included? Requests and support hours per buyer
Variable cost Does every active user create storage, video, AI, or support cost? Cost per active buyer per month
Engagement What action signals that the core job was done? Users who build or complete a sequence
Subscription bridge Who can later buy recurring value without paying twice? New recurring customers and renewals
Reputation What happens if a promised feature slips? Complaints, refund requests, referrals

The ledger forces an honest question: if every lifetime buyer remains active, can the company serve them without taking future subscribers' revenue to cover past obligations? There is no universal cap on the number of lifetime buyers. The cap follows the product's unit costs, the team's delivery capacity, and the price collected. A founder with expensive per-user compute or high-touch support should set a much stricter limit than a founder distributing a static library.

Do the cohort calculation before the announcement

Suppose a proposed $100 lifetime offer has $8 in fees and expected refunds, $12 in acquisition cost, and an estimated $2 per active customer per month in variable service cost. The $80 remaining after immediate costs supports forty months of that variable cost, before fixed development and support. If actual monthly cost rises to $5, the same cash covers sixteen months. These are hypothetical figures to illustrate the decision; they are not Floga's economics.

Now ask how many lifetime buyers will actually remain active, how long, and what happens when new features increase service cost. Model a conservative and a high-use cohort. A low-use cohort may be cheap but also suggest the product has not delivered continuing value. A highly engaged cohort is great for learning and potentially costly to serve. Both scenarios need room in the plan.

Offer clarity is part of trust

Floga's public pages reviewed for this draft illustrate why an offer needs a single current source of truth. The product site includes recurring monthly, quarterly, and yearly language alongside older one-time and lifetime-sale language, while the terms distinguish renewable subscriptions from lifetime packages. A visitor should be able to tell exactly which option is being purchased, whether it renews, what access survives cancellation, and whether the checkout is on the web or in an app store. Sources: current product page and terms of use.

This observation is about what the public pages display, not a claim that a particular buyer was charged incorrectly. Offer pages change frequently, and the final checkout terms control a specific transaction. For a founder planning a similar launch, the practical rule is to review every live landing page, email, FAQ, checkout, and support response as one system. Old urgency copy left beside a new recurring plan can turn a trust advantage into confusion.

The App Store listing confirms that Floga exists as an iOS app with in-app purchase options. It does not verify the claimed launch receipts or active-user count. That is why it serves a different evidentiary role from the founder interview. Source: Apple App Store listing.

Oddig's audience-transfer test

Use this test before offering a new product to an existing audience. It is designed for a small team with a newsletter, course, community, physical product, or service; it does not assume a fixed launch period.

Step 1: Define the adjacent job. Write down what buyers currently do with the old product and what they would do differently with the new one. Name the person who benefits. If you need a long explanation to connect the two, you may be testing a new market rather than extending an existing one.

Step 2: Show the bridge in use. Demonstrate one end-to-end task to existing customers. For Floga's kind of product, that would be taking a sequence someone would build with cards, creating it in the app, and using the resulting flow. Ask what changed in effort, control, or enjoyment. Record objections verbatim.

Step 3: Price the smallest honest offer. State what exists now, what is planned, the delivery date or review milestone, support terms, refund terms, and any lasting obligations. A pre-sale can be for a limited function rather than an unlimited future. Ask buyers to pay for the clearly described offer.

Step 4: Compare cohorts. Track existing customers separately from people who did not know the brand. Record the path from impression to purchase, then from purchase to the core action and continued use. If only loyal customers buy, the result validates an audience-funded extension. It does not yet validate broader acquisition.

Step 5: Decide the next financing path. If customers complete the core action and some new buyers pay, test subscriptions or add-ons. If buyers only wanted to support the brand, improve the product before scaling promotion. If fulfillment burden exceeds the original estimate, pause new lifetime offers and resolve the obligations already sold.

Choose the thresholds that fit the job before selling. For example, a team might require most early buyers to create a sequence, a meaningful share to use it again at their next practice, and support demand low enough to serve without delaying development. Those are proposed criteria, not external benchmarks. The key is that the sale, first use, and repeat use are counted separately.

The case's limits

Floga had a prior audience, a physical product tied closely to the proposed app, and a brand story customers could already understand. A founder with a generic list of followers or an unrelated product cannot assume the same conversion. A screen-free audience may also evaluate a digital extension more critically than a software-first audience; that makes positioning and product demonstration essential.

The founder's monthly figure combines subscription and annual-plan cash, so the public material does not permit a clean recurring-revenue calculation. The pre-sale figure is also a self-report. The strongest conclusion is about the sequence of decisions: use a related audience to fund an honest early offer, then learn from product use and introduce a more sustainable recurring model when the service is ready. Do not turn a one-day sales number into a template for every app launch.

For a founder reading this before an announcement, the useful decision is simple: write the delivery promise and service-cost ledger before the launch email. If those two documents are incomplete, the audience's trust is not yet a reason to ask for money.

Related Oddig reading

Sources and method

Oddig did not inspect Floga's sales records, refund data, active-user dashboard, or private customer communications. The ledger and audience-transfer test are original editorial tools, not calculations of Floga's actual margin. Offers and checkout terms can change over time.

Still building?

Get the next useful signal in your inbox.

    Unsubscribe anytime. Privacy.