January 2026 Report

January 2026 Neon Apps Activity and Outcomes Report

1. Executive Summary

Managed Portfolio Overview

• The number of Neon managed RevenueCat clients increased to 27, each supported through a dedicated Slack channel
• Same day responses provided across technical, product, and monetization topics
• Hands-on support delivered across paywall design, growth guidance, experimentation, and SDK-level implementation
• Neon managed clients generated approximately $11.7M in total Monthly Tracked Revenue (MTR)
• Last invoice volume of Neon managed clients was approximately $90K Client Execution & Retention
• Completed multiple Adapty → RevenueCat migrations in production
• Prevented churn among large publishers through direct coordination and pricing alignment
• Moved several strategic accounts from exploration into active testing and evaluation phases Ecosystem & Top-of-Funnel Growth
• Launched the RevenueCat Türkiye Telegram community
  • Reached approximately 200 members
  • Maintained through localized explanations and Turkish Loom videos
  • Established a strong local knowledge and support hub
• Completed full preparation for the RevenueCat Türkiye App Growth Championship
  • Finalized event structure, branding, timeline, and landing page
  • Positioned as a long-term initiative focused on early adoption, brand visibility, and inbound lead generation Strategic Impact
• Strong execution and retention continue to be core strengths
• Community and ecosystem initiatives are laying the groundwork for sustainable inbound demand
• February focus will prioritize mid-sized and fast-growing publishers, supported by these GTM efforts

---

2. Existing Client Support & Enablement Highlights

Below are examples of hands-on support provided to managed RevenueCat customers during January. These cases reflect recurring support themes across the broader portfolio.

Most Important Cases

• Teknasyon

  Teknasyon was previously using RevenueCat only for basic charts. After convincing them to move to an annual contract, we held a dedicated session to walk through the full set of RevenueCat features they wanted to adopt, including paywalls, experiments, targeting, and real time charts.
  Following this, we created a clear rollout roadmap. We are currently integrating these new features into one of their apps, and the same setup will be gradually rolled out to the rest of their portfolio.

• Madduck

  We had around four meetings with Madduck throughout the month and stayed in continuous communication via Slack. Some of their apps are already using RevenueCat as a test process, but they often run into challenges or confusion when trying to use certain features.
  In these cases, we stepped in consistently. We guided them through the full process, explained features in detail, worked directly on the code with their team, designed multiple paywalls, and helped them effectively use tools such as real time charts, the paywall builder, and other key RevenueCat functionalities.

• Scate

  We had frequent touchpoints with Scate throughout the month, including multiple calls and ongoing Slack communication. Most of the support focused on advanced RevenueCat implementations rather than basic setup. We actively helped Scate troubleshoot complex scenarios around offerings, price testing, and targeting logic. This included identifying issues caused by mixing Firebase Remote Config–driven logic with RevenueCat offerings, clarifying how purchases were being triggered at the SDK level, and explaining why certain offerings or experiments were not reflected correctly in reports or dashboards. In addition to technical guidance, we worked closely with their product and design teams on paywall strategy. We supported the migration of existing in-app paywalls into RevenueCat Paywall Builder, advised on handling multiple paywalls and alternative offerings, reviewed introductory offer usage, and helped align which products should appear on which paywalls. We also shared educational resources, walkthroughs, and Loom videos to explain features such as targeting, placements, and virtual currencies, and coordinated with both their development and design teams to ensure correct implementation. Overall, our involvement went beyond Q&A support and included hands-on troubleshooting, architectural guidance, and direct collaboration to help Scate fully leverage RevenueCat’s advanced capabilities.
  • Investigated cases where purchases were attributed to different Offerings despite users seeing a single paywall.
  • Identified that purchases were being triggered via purchaseProduct instead of purchasePackage, causing RevenueCat to log transactions under No Offering.
  • Explained how RevenueCat sets the Offering flag at purchase time and why direct product purchases bypass Offering attribution.
  • Reviewed SDK purchase flow and confirmed that correct attribution requires using package-based purchases.
  • Analyzed Firebase Remote Config–driven paywall logic and identified mismatch with RevenueCat Experiments and Targeting.
  • Clarified that RevenueCat cannot see Firebase-side experiment decisions, leading to inconsistent dashboard data.
  • Recommended moving paywall targeting and experiments fully into RevenueCat to ensure accurate reporting.
  • Reviewed Audit Logs and confirmed offering_default_updated events and Offering assignment behavior.
  • Supported RevenueCat Paywall Builder usage, including:
  • Checked introductory offer configuration and verified why intro offers were not displayed.
  • Designed multi-paywall setup including main paywall, offer paywall, and feature-based secondary paywalls.
  • Advised on structuring multiple Offerings and mapping products correctly across them. January 2026 Neon Apps Activity and Outcomes Report
  • Provided guidance on Virtual Currency feature usage and subscription-credit logic for their app.

Other Example Support Cases

• PlusMinusOne

  What They Asked
  • Whether global price tests distribute users equally between control and treatment per country
  • If users coming from different campaigns (A, B, C) are evenly split across variants within their own campaign
  • How RevenueCat experiments handle campaign-level attribution
  • Why “New Paying Customers” count in Data Export does not match Cohort Explorer
  • How to write a correct SQL query to replicate RevenueCat dashboard metrics How We Helped
  • Explained clearly that RevenueCat experiments do not distribute traffic at campaign level, only at user level
  • Clarified that campaign-based separation must be handled via Custom Attributes + Targeting, not Experiments
  • Confirmed that users are assigned to variants deterministically by user ID, independent of campaign source
  • Escalated the Data Export discrepancy internally and identified the root cause:
    • Dashboard counts users based on first successful paid conversion, not first_seen_time
    • Trial-to-paid conversions in later periods were missing from the original query
  • Provided a corrected SQL query using:
    • first_paid_purchase
    • Trial exclusion
    • Refund filtering
    • Proper cohort month grouping
  • Helped them align Data Export numbers with Dashboard and Cohort Explorer
  • Issue was confirmed resolved by the client after query correction

• Apptribe

  What they asked
  • Wanted to add RevenueCat Paywall Builder to an existing app
  • Asked for help on technical integration and Paywall Builder setup
  • Requested design support, including aligning paywall structure with their existing product flow
  • Needed guidance on handover and collaboration between product, design, and RevenueCat dashboard access How we helped
  • Coordinated directly with product and design stakeholders (product owner and designer included in the thread)
  • Assisted with Paywall Builder configuration on the RevenueCat dashboard
  • Completed the builder handover, confirmed setup, and offered post-delivery adjustments if needed
  • Ensured the paywall was ready for implementation without blocking their release timeline

• Voyager Application

  What they asked
  • Asked whether RevenueCat Data Export v5 includes a column for bundle_id.
  • Asked how other companies retrieve app bundle IDs when pulling RevenueCat data.
  • Raised a concern about a suspicious IAP transaction appearing as coming from “iPhone 18.1” and whether this could be fraud.
  • Needed clarification on device identifiers used in RevenueCat and Stitch Loop. How we helped
  • Clarified that bundle_id is not directly available in Data Export v5.
  • Explained alternative approaches:
    • Using the platform field.
    • Passing bundle_id via custom attributes if required.
  • Investigated the “iPhone 18.1” case and explained that:
    • This value represents chip generation, not the actual device name.
    • Multiple iPhone models can share the same identifier.
  • Shared a public GitHub reference list showing Apple device identifiers to confirm legitimacy.
  • Confirmed that the transaction was not fraud-related and aligned with Apple’s device mapping. January 2026 Neon Apps Activity and Outcomes Report

• MobileOcean

  What they asked
  • How RevenueCat project transfer works during an app ownership change.
  • Whether Apple App Store transfer requires any RevenueCat-side action.
  • How to handle Google Play service credentials (JSON) during transfer without breaking transaction validation.
  • Risk of purchase interruptions during the exact transfer window. What we did
  • Explained the RevenueCat project transfer flow, including the requirement to first add the target account as a collaborator before initiating transfer.
  • Designed a zero-downtime Google Play migration plan:
    • Instructed them to pre-create the new Google service account and JSON key before transfer.
    • Explained how RevenueCat temporarily retries validation if credentials change.
    • Clarified the exact short risk window (only new purchases during the few minutes between transfer approval and JSON update).
  • Provided step-by-step guidance on when to upload the new JSON in RevenueCat to avoid failed validations.
  • Clarified edge cases:
    • Existing subscribers are not affected.
    • Only brand-new purchases during the exact handover window may see brief delays, not permanent failures.
  • Stayed in-thread until MobileOcean confirmed they fully understood and proceeded with confidence.

• Mobiversite

  • Paywall UI and responsiveness issues
    • Reviewed RevenueCat paywalls migrated from custom designs.
    • Identified layout and scaling issues on small screen devices where elements were compressed or partially hidden.
    • Designed new paywalls
  • RevenueCat Paywall Builder optimization
    • Collaborated with design team to improve paywall layout using RevenueCat templates.
    • Reviewed and validated updated paywall drafts created in RevenueCat Builder.
    • Ensured pricing options, CTA hierarchy, and visual consistency were preserved after migration.

• Byterise

  • Investigated missing firebaseAppInstanceId in RevenueCat webhooks for renewal events and identified timing mismatch between event creation and attribute initialization.
  • Explained why the ID was not included in historical renewal payloads and confirmed it is now correctly set for future events.
  • Clarified RevenueCat webhook snapshot behavior and how attributes propagate across lifecycle events.
  • Advised on best practice to send firebaseAppInstanceId early in the app lifecycle, before purchase flows, to avoid recurrence.
  • Reviewed non-subscription A/B test setup where experiment data was skewed toward subscriptions.
  • Identified misconfiguration related to the “for all other cases” placement overriding consumable tests.
  • Provided a corrected experiment setup approach using proper placements and default offerings to ensure non-subscription purchases are tracked correctly.

• PixelByte

  What They Asked
  • Investigated why their specific Targeting rules were not functioning as expected.
  • Sought clarification on the conflict and priority logic when using Experiments and Targeting simultaneously.
  • Questioned why users were bypassing targeting conditions and seeing unexpected offerings. How We Helped
  • Clarified the RevenueCat logic hierarchy, explaining that active Experiments override standard Offering Targeting.
  • detailed that once an experiment is created, it takes precedence, and the system applies the default case logic differently than in a targeting-only setup.
  • Conducted meetings to review their specific console configuration.
  • Corrected the default case usage to ensure that users not enrolled in the experiment (or falling out of scope) are routed to the correct offering.

• Unico

  What They Asked
  • Reported a UI issue with Remote Paywalls where two "close" buttons were appearing on the screen.
  • Confirmed that the RevenueCat dashboard configuration did not include a duplicate button.
  • Requested an investigation into why the paywall UI was rendering incorrectly despite the clean dashboard setup. How We Helped January 2026 Neon Apps Activity and Outcomes Report

• Feraset Full demo completed with strong product interest and clear product fit. Deal stalled due to a significant pricing gap compared to their existing Adapty setup, resulting in a 100%+ perceived cost increase. This case reinforced a broader challenge with large Adapty enterprise accounts despite strong RevenueCat capabilities. Account will remain in a long-term nurture track.

---

5. Blockers, Challenges, and What Didn’t Work

Large Account Acquisition

• Neon Apps has strong access to large Turkish publishers, but for companies currently using Adapty, RevenueCat pricing is often perceived as 200%+ more expensive, similar to the Feraset case.
• As a result, several large deals are blocked despite strong product fit and interest.

Inbound Lead Generation

### **What Is Working** - Small accounts GTM activities are performing well and expected to compound over time. - Retention, support quality, and delivery execution are strong. ******* ## **6. Local Market Insights** We’ve realized that the pricing challenge described [here](https://neon-apps.slack.com/archives/C09N4RT3M09/p1769003148898189?thread_ts=1766129671.966249&cid=C09N4RT3M09) will make it difficult to attract large Adapty accounts, mainly due to the %200–%800 pricing difference. Because of this, our focus should shift toward mid-sized and fast-growing small accounts in Turkey, where growth momentum is strong and adoption barriers are lower. ******* ## **7. February 2026 Focus** 1. **Launch App Growth Championship** - Publish landing page - Announce publicly and start collecting applications - Collaborate with RevenueCat on paid campaigns to drive applications and brand awareness 1. **Inbound Lead Generation Collaboration** - Work with RevenueCat to identify and test ways to generate more inbound leads - Enable Neon Apps sales team to run more demos for mid-sized accounts 1. **Pipeline Progression** - Continue Madduck testing toward a decision - Support Pulca app release post-migration - Maintain nurture relationships with large Adapty accounts (Feraset, Papcorns) -