Ordy AI

The B2B mobile platform that centralizes management and AI agents for SMEs, ensuring scalable and secure monetization through in-app purchases using Google Play Billing and RevenueCat.

Comment

Inspiration

The core inspiration behind ORDY AI was to build a commercially viable product from day one, strictly adhering to RevenueCat Shipaton 2026 (the “Hackathon”) requirements: a functional app launched between August and September 2026, featuring global accessibility (including the US) and a robust monetization architecture managed entirely via the RevenueCat SDK.

Recognizing the friction businesses and SMEs face when adopting artificial intelligence, the decision was made to develop a mobile B2B solution. Business owners do not need more disconnected apps; they need a unified, high-performance tool. The goal was to transform an Android device into an operational hub where AI serves not merely as a generic chatbot, but as a structured tool—featuring contextual push notifications and C-level-style assistance—that processes purchases and securely scales permissions using RevenueCat.

What it does

ORDY AI is a native Android application (packaged with Capacitor) designed to strictly meet the launch and transactional requirements of the Shipaton. Its goal is to centralize the operational management of an SME, utilizing an in-app monetization architecture fully managed by the RevenueCat SDK.

To compete directly for the HAMM Award, I structured the AI ​​functionalities not merely as software tools, but as commercial assets with access governed 100% by RevenueCat and Google Play Billing:

Transactional Infrastructure and Paywall: ORDY AI is a viable commercial product from day one. The app's core connects to the RevenueCat SDK to process real in-app purchases. I implemented a tiered SaaS model (Pro, Business, and Enterprise plans) that dynamically handles receipt validation and upgrade/downgrade logic directly on the device, ensuring frictionless monetization.

Quota-Based Executive Intelligence (C-Level): The application offers a virtual corporate board (AI configured as CEO, CFO, COO, etc.), but access is strictly controlled by RevenueCat entitlements. Depending on the plan purchased via Google Play Billing, the RevenueCat SDK grants different access levels and usage quotas. A Pro plan limits daily interactions and restricts certain profiles, whereas the Enterprise plan reads the active receipt via RevenueCat and unlocks unlimited, real-time queries across the entire C-Level suite.

Subscription-Tiered IIE Engine: The segmented push notification algorithm (IIE Engine) serves as the app's primary retention tool, and its execution is contingent upon the RevenueCat SDK. This premium feature verifies the subscription status before dispatching any operational alerts to the business. If the user downgrades, cancels, or the Google Play payment fails, RevenueCat instantly revokes the entitlement, and the IIE Engine blocks access to strategic alerts. This directly links a high-value feature to the requirement of maintaining an active subscription.

How we built it

ORDY AI is a native B2B Android application (built using Capacitor) created specifically to meet the requirements of the Shipaton. It is published on Google Play, and its transactional core relies entirely on the RevenueCat SDK to manage in-app purchases via Google Play Billing.

My goal for the HAMM Award was to go beyond a simple visual paywall. I designed a two-dimensional access architecture where business logic evaluates the user's role (RBAC) and cross-references it in real-time with their subscription plan (provided by RevenueCat) to enable specific features:

Transactional Infrastructure (RevenueCat SDK): The app's core is a viable commercial product featuring a tiered SaaS model (Free, Pro, Business, and Enterprise plans). I use RevenueCat as the single source of truth to validate Google Play receipts and manage complex upgrade/downgrade logic directly on the device.

IIE (Business Impact Index) Engine and Paywall: I developed the IIE Engine—the core algorithm of the Focus Engine—which evaluates business events and assigns them a mathematical score (1.0 to 10.0) based on impact and urgency. All users (including those on the Free plan) can view these cards and scores, but the engine's operational execution is strictly governed by RevenueCat.

The app's native logic queries entitlements via RevenueCat: if a Pro or Business plan is detected, the code unlocks advanced data connectors (ERP, CRM) and enables mobile push notifications exclusively when an event exceeds the "Critical" threshold (IIE ≥ 8.0).

If the user cancels their subscription, RevenueCat revokes the entitlement, and the app automatically downgrades the IIE engine's capabilities, silencing push alerts and limiting the system to manual data entry. Executive Intelligence (Virtual C-Level) and RBAC Control: The application automatically assigns resolutions via specialized AI agents (CEO Agent, CFO Agent). Access to this executive suite relies on a two-step validation process: first, RevenueCat must confirm an active Pro/Business plan to enable the invocation of these agents and their automated resolutions. Second, the internal permissions engine (RBAC) verifies the user's role: only Owners and Admins have permission to modify the algorithm's weighting rules, whereas a Manager can approve AI-generated decisions. If the plan validated by RevenueCat is Enterprise, an additional layer is unlocked, allowing for the customization of algorithmic weights to suit the corporation's specific needs.

Challenges we ran into

During the process of integrating RevenueCat into ORDY AI’s hybrid architecture (Web + Capacitor Android), the main technical and operational challenges I faced were as follows:

  1. Coexistence of Web (LemonSqueezy) and Mobile App (Google Play Billing)

The challenge: In the web version (desktop browser), payments are processed via LemonSqueezy; however, strict Google Play policies prohibit redirecting users to external web payment gateways from within an Android app to purchase digital content or subscriptions.

The implemented solution: A native interceptor was created in MainActivity.java (injectRevenueCatLemonInterceptor) that detects any click or attempt to open LemonSqueezy links and immediately cancels the action, instead launching the native Google Play Billing dialog via RevenueCat.

  1. Communication Bridge between Native Java and React/WebView

The challenge: RevenueCat runs on the native Android SDK (Java/Kotlin code), whereas the user interface, plan catalog, and user status reside within the WebView using React/TypeScript.

The implemented solution:

A native JavaScript interface (@JavascriptInterface WebAppInterface) named AndroidNative was configured.

Methods included purchaseMonthly(), purchaseAnnual(), restorePurchases(), and checkProEntitlement().

To return responses to React without blocking the main thread, asynchronous callbacks were used—evaluating JS code via mainWebView.evaluateJavascript(...)—alongside custom events such as ordyProStatusChanged.

  1. Real-time Subscription Status Synchronization (Entitlements)

The challenge: When a user completes a purchase via the Google Play dialog, the app must instantly unlock Pro benefits (plans, token limits, advanced AI features) without requiring an app restart or a manual refresh. Implemented solution: The RevenueCat listener setUpdatedCustomerInfoListener was configured:

Java Purchases.getSharedInstance().setUpdatedCustomerInfoListener(customerInfo -> { EntitlementInfo entitlement = customerInfo.getEntitlements().get("ordy_ai_pro"); boolean isActive = entitlement != null && entitlement.isActive(); ... }); This triggers a global event in the WebView DOM as soon as Google Play confirms the transaction.

  1. Handling "Restore Purchases"

The challenge: Google Play requires any app with subscriptions to offer a clear, accessible way to restore existing purchases if the user switches devices or reinstalls the app.

Implemented solution: The native "Restore Purchases" button was integrated into the native Pro modal; it calls Purchases.getSharedInstance().restorePurchases() and displays immediate feedback via a native Android Toast.

  1. Key Configuration and Native Build Dependency

The challenge: RevenueCat credentials (revenuecat_public_key) and Google Play Console product configurations require synchronization across the capacitor.config.ts file, strings.xml, and the RevenueCat console. The app must not crash if the key is missing or if Google Play Services are inactive on the device.

Implemented solution: All calls were wrapped in try/catch blocks with Purchases.isConfigured() checks, ensuring that the app continues to function without crashing if the service fails or is offline.

Accomplishments that we're proud of

There are five outstanding achievements regarding the integration of RevenueCat into ORDY AI that we are particularly proud of. It wasn't simply a matter of "adding a payment gateway," but rather solving a highly complex hybrid engineering problem—one that takes many companies months to resolve:

  1. Google Play "Rejection Shield" (Transparent Interception) ⭐ (The biggest achievement) Why it’s a major feat: Google Play suspends or rejects apps that include links or buttons pointing to external web-based payment gateways (such as LemonSqueezy or Stripe) for in-app digital purchases. The achievement: We designed a native interceptor (injectRevenueCatLemonInterceptor) that dynamically monitors the DOM. On desktop web browsers, LemonSqueezy functions as usual; however, on Android, any purchase attempt or click is silently and instantly intercepted, triggering the native Google Play flow via RevenueCat. This ensures 100% compliance with Google’s policies without altering the web version.
  2. Native Payment Architecture Without Modifying Core React Code Why it’s a major feat: In packaged hybrid apps (Capacitor/WebView), mixing native purchase logic often breaks the frontend or clutters the web code with if (isAndroid) ... else ... statements. The achievement: We created a clean, decoupled bridge (AndroidNative) using an injected JavaScript interface. The web application remains pure and standard, while the native Android layer handles the orchestration of dialogs, local currency pricing, and Play Store calls. 3. Real-Time Pro Benefit Synchronization (Zero Latency) Why this is a major achievement: Typically, after paying via Google Play, many apps force users to wait, restart the app, or log in again for the Pro plan to be recognized. The achievement: We implemented the reactive setUpdatedCustomerInfoListener. As soon as Google Play validates the user's card or payment, a custom event (ordyProStatusChanged) is emitted directly to the WebView window. Users see tokens and Pro tools unlock in under a second, without the screen reloading.
  3. Elegant and Resilient Native Purchase Dialog Why this is a major achievement: Purchase interfaces that rely entirely on web technologies can fail due to asset loading issues or rendering delays. The achievement: We designed the plan selector (showProOptions) using native Android views (Dialog, Button, TextView) and brand typography. It loads instantly, clearly displays the monthly and discounted annual plans, and includes the mandatory "Restore Purchases" button, ensuring a significantly higher conversion rate.
  4. Robustness and Stability Against Network Failures Why this is a major achievement: If a user attempts a purchase without a signal, or if the Play Store experiences delays, many apps freeze or crash ("the application has stopped"). The achievement: All communication between RevenueCat and the WebView features asynchronous error handling and structured JSON responses ({"status":"error"|"cancelled", ...}). If the user cancels the purchase, the app handles it gracefully; if the connection drops, there are no system lockups or frozen screens. In short: we achieved an enterprise-grade monetization experience that is 100% compatible with Google Play, without compromising a single line of the ORDY AI web version.

What we learned

Integrating RevenueCat into a hybrid solution (Web + Capacitor Android) was far from a textbook exercise; it was a real-world software engineering scenario where two completely distinct ecosystems converged. Throughout this development process, I gained invaluable technical insights:

  1. The boundary between "Web" and "Native" becomes invisible yet crucial: I learned that while a Capacitor app looks and feels like a single application, two worlds with different rules coexist beneath the surface: the JavaScript UI thread (React/DOM) and the operating system's main thread (Android/Java). Knowing when a task belonged to the WebView versus when it needed to be handled by native Android was the key to architectural success.

  2. Google Play policies are not a technical obstacle, but a design requirement: Instead of viewing Google's restrictions on external payment gateways (like LemonSqueezy) as a hindrance, I learned to orchestrate a smart coexistence strategy. I designed the system so that desktop users pay seamlessly via the web, while mobile users pay with a single tap on Google Play via RevenueCat—leveraging the security and trust associated with their Google accounts.

  3. The value of orchestration and technical leadership: I learned to efficiently coordinate complementary tools—the web/cloud core on one hand, and Android Studio for compilation and the native bridge on the other. I was able to translate requirements between environments with surgical precision, ensuring that each component performed exactly the task it was best suited for.

  4. User experience (UX) regarding payments is sacrosanct: I grasped the vital importance of designing for intermediate states: what happens if the user cancels the purchase, what occurs if there is no internet connection during a restore attempt, and why unlocking "Pro" features must be instantaneous—without page reloads that would disrupt the app's fluidity. 5. Strict decoupling to avoid code contamination: A common temptation in hybrid projects is to clutter the React code with conditionals like if (window.isCapacitor).... My key takeaway here was to keep the frontend agnostic and clean: my web code remains standard, while the native layer I injected into Android (BridgeWebViewClient + @JavascriptInterface) handles intercepting and adapting workflows. This ensured the web version remained fast, maintainable, and free of unnecessary native dependencies.

  5. Resilience and asynchronous two-way communication: I learned to structure native bridges based on decoupled events (CustomEvent('ordyProStatusChanged') and parameterized JSON callbacks). Data exchange between Java and JavaScript cannot rely on assumptions of synchronicity; I realized the code must be resilient to network delays, unexpected dialog closures, and non-linear responses from Google Play.

  6. Defensive handling of the mobile lifecycle: A mobile app can lose its connection, be sent to the background, or be paused at any moment during a transaction. Designing this integration taught me that every call to the RevenueCat SDK must be robustly protected with pre-configuration checks (Purchases.isConfigured()) and try/catch blocks to prevent fatal crashes that would close the application.

  7. The synergy of modular work: I mastered the workflow of creating modular, agnostic frontend solutions and seamlessly transferring them to Android Studio, paying close attention to avoiding dependency conflicts in Gradle and inconsistencies in the Android manifest.

In summary: I learned that the true maturity of a modern B2B SaaS application lies not in rebuilding everything from scratch for each platform, but in building intelligent bridges that respect the strengths and regulations of each transactional environment.

What's next for Ordy

The current infrastructure proves the business model works, but my strategic roadmap for ORDY AI focuses on scaling the RevenueCat integration through four high-impact steps:

  1. RevenueCat Webhooks to Firestore (360° Omnichannel Synchronization)

Where I am today: When a user makes a purchase on Android, the mobile app unlocks Pro benefits in real-time.

The next step: Connect RevenueCat Webhooks to a secure endpoint on my backend (/api/webhooks/revenuecat).

Why it’s key: If a customer purchases a subscription via their Android phone on the Play Store, their account must automatically become "Pro" when they open ORDY on their desktop computer. If they cancel or renew, the webhook will update their Firestore document (organizations/{orgId}/billing) in a fully automated manner, ensuring a seamless cross-platform experience.

  1. Dynamic Paywalls and A/B Testing via RevenueCat

Where I am today: I have a native purchase dialog with static buttons and pricing (Monthly/Annual).

The next step: Implement RevenueCat Paywalls and dynamic Offerings.

Why it’s key: I will be able to change prices, iterate on the design, create special promotions (e.g., "50% off"), or enable trial periods directly from the RevenueCat web dashboard—without needing to build a new .aab file or wait for Google Play review times.

  1. Expansion to the Apple Ecosystem (iOS App Store)

Where I am today: ORDY AI operates on the Web (LemonSqueezy) and Android (Google Play Billing).

The next step: Build the iOS target using Capacitor in Xcode for the App Store.

Why it’s key: Since the payment core was built on RevenueCat, 90% of the work is already done. The same SDK and entitlement logic (ordy_ai_pro) will work identically with Apple’s StoreKit. I won’t need to rewrite the commercial architecture; I simply need to link the products in the console.

  1. Advanced Metrics and Churn Management (Retention)

Current state: I process individual transactions and manage access via entitlements.

Next step: Enable RevenueCat’s advanced analytics (MRR, LTV, Churn Rate) and link payment status to the IIE Engine.

Why it’s key: If a credit card enters a grace period (billing retry), the IIE Engine will be able to detect the RevenueCat event and send an empathetic, proactive push notification, helping the user update their payment method before the system revokes access to their AI board of directors.

In short: The next phase for ORDY with RevenueCat involves evolving from a standalone transactional app into an omnichannel B2B ecosystem driven by data-informed decisions and automated retention.

Built With

Share this project:

Updates

Submission history