Mobile App Deployment in the Real World: Subscriptions, Services, and Platform Realities (Part 3)

Mobile app deployment is where many promising ideas start to encounter real-world friction. What worked as a prototype suddenly has to meet the expectations of app store ecosystems, subscription models, and an increasingly complex stack of services.

In this third part of the Pennies-AI journey, we’ll explore what it actually takes to navigate the maze of mobile deployment and monetization. Shipping a modern app means coordinating a wide range of platforms and providers, from infrastructure services like Hostinger, GitHub, and Heroku, to ecosystem gatekeepers such as Apple and Google, along with tools like Expo, RevenueCat, and Stripe.

Earlier in the series, we covered how Pennies-AI evolved from idea to working prototype, the architecture choices, the tools that fit the product, and why even seemingly “simple” features can be deceptively complex. We then moved into the realities of production, like hardening the system, managing risk, and understanding the ongoing costs of keeping a product reliably available across web and mobile environments.

Before getting too deep into deployment details, it’s worth stepping back to think about how your app actually operates as a product. That includes how subscriptions are structured, how users gain access to features, and how all of these platforms and services connect behind the scenes.

Mobile App Deployment Requires More Than Code

There are quite a few services and platforms you’ll need to set up in order to run a production website and mobile apps that support subscriptions. Configuring everything yourself can be painful, but it is often far less expensive than paying someone else to handle the entire process.

The upside is that you’ll gain a deep understanding of how each part of your business operates. When you know how everything fits together, it becomes much harder for anyone to take advantage of you.

Hostinger

The first thing you’ll need is a domain name for your website. Without one, you won’t be able to do much of anything else. I chose Hostinger because of its low cost, the ability to manage all domain records yourself, and built-in email support with SMTP so you can send messages to your users. Of course, you can use any provider you prefer.

For many of the services discussed below, you’ll need to add specific records to your domain (like MX and CNAME) to verify ownership.

Github

There are various sites that can store your code, but Github is the most popular. It also integrates very well with Heroku. You can sign up for a GitHub account using your company email address, then create an organization after signing in to your personal GitHub account.

In the top-right corner, click your profile picture and select “Your organizations” from the dropdown menu. On the organizations page, click the “New organization” button. I’m currently using the free plan.

Heroku

Again, there are a lot of hosting options out there (including Hostinger, mentioned above). I use Heroku because it’s low cost and provides excellent support for setup, deployment, and performance. Its integrated services, such as Postgres, make it possible to manage most hosting needs in one place.

As mentioned in the previous blog, be sure to let Heroku manage your SSL certificate for you (it’s free!).

Apple

Create your Apple business account first. Once that is complete, you can create your Apple Developer business profile. There is a $99 per year fee.

Getting everything set up (along with successfully passing the app review process) is probably the most painful part of this entire journey. Be patient and go in knowing that it will take many tries to provide everything Apple requires in the correct format and location. I could walk through the full process here, but it would easily fill an entire book by itself.

Google

Create a Google account for your business (hint: you can choose “For myself” and enter your business email; a Google Workspace account is not required). Once the account is created, you can set up your Google Play business account.

You will also need to enable certain services in Google Cloud so RevenueCat can see when users subscribe. We’ll come back to that in just a bit.

Expo

Expo offers several valuable tools for mobile developers. First, they have a wide range of React-Native components that make building apps easier. Second, they have a build framework for creating both development and production builds.

I initially used Expo’s website to run builds, but later discovered I could run them locally. Building locally is a much better option because there are no limits on the number of builds, and you do not have to wait in a queue. I’m currently using Expo’s free tier and will only need to upgrade to the first paid tier once I exceed 1,000 monthly active users (yes, please!).

Building Locally:

export NODE_ENV=production && eas build -p android --profile production --local

export NODE_ENV=production && eas build -p ios --profile production --local

For Google, I create a new release in the Google Play Console and drag the generated .aab file into the upload window.

For Apple, I create a new release in App Store Connect and then use Expo’s CLI to submit the build automatically: eas submit --platform ios Apple processes the build, and when it is finished I can choose the build to be included in the release.

With the major platform accounts and build pipelines configured, the next challenge is managing subscriptions consistently across web and mobile, which is one of the most complex aspects of mobile app deployment. Now, we’re moving from infrastructure to subscriptions.

RevenueCat

RevenueCat provides a critical service: tracking subscriptions across web and mobile so your users don’t have to pay multiple times. This is accomplished by having your code create a unique subscription ID for each user. During setup, don’t choose the automatic ID. Instead, create it yourself. This allows you to store it in the user’s profile so that when a webhook is triggered, you can link the subscription ID back to the associated account.

Setting Up Subscriptions and Paywalls

The subscriptions configured in RevenueCat paywalls originate from each provider (Stripe, Apple, and Google). You have to first set them up with the provider, complete the review process to get them approved, and then use the generated IDs in your paywall config. One thing to note about subscriptions: set them up as in-app purchases. If you set them up as standalone subscriptions, Apple and Google may require users to pay before they can even download the app. In-app purchases allow users to install the app first and give you the flexibility to offer your own trial period before directing them to the paywall.

RevenueCat paywalls make it possible to manage the subscription payment experience. I created one paywall per platform and used Targeting (you’ll see it on the RevenueCat dashboard) to determine which paywall to display. You will also need to configure hooks in Apple and Google, so they notify RevenueCat whenever subscription activity changes. RevenueCat then sends a webhook to your server so you can process those events.

Handling Webhooks and Subscription Events

The events passed in the webhook let your server update user profiles with current subscription information. Webhooks are also one of RevenueCat’s free integrations (navigate to Integrations → Webhooks in the dashboard to create one). Expect to spend a fair amount of time testing to ensure you correctly handle the various event types. The type field tells you what type of event has been sent. Pay close attention to fields such as expiration_at_ms, purchased_at_ms, and grace_period_expiration_at_ms, as they are used differently across events to indicate when a subscription expires.

In the RevenueCat dashboard, you can navigate to Customers → Active Subscriptions (or Sandbox for testing) to view a list of customers by ID. Clicking on an ID shows you the event with all associated data. Reviewing these can help you understand the fields included with each event and guide how you process them in your webhook code.

Testing and Pricing Considerations

Like many modern developer platforms, RevenueCat offers a free tier until you reach a certain threshold. In this case, $2,500 per month in generated revenue (again, yes please!).

RevenueCat also has a very good SDK, solid documentation, responsive support, and reliable sandbox integrations, making it possible to thoroughly test subscription flows before releasing them to production.

The biggest drawback is that users must manage their subscriptions through the platform where the purchase was originally made (whether that is the web (Stripe), Apple, or Google). Each provider offers subscription management tools, and you can link directly to those pages to help users make changes or cancel. On my subscription page, I clearly indicate where each user’s subscription was purchased and how they can manage it, which helps reduce confusion.

Each provider has support for all of this, and you can link to those pages to get your users directly to those management pages. What I do on my subscription page is tell the user where their subscription was purchased from and how to manage it, which reduces confusion.

To get started through the long road of setup with RevenueCat, start here.

Stripe

While Apple and Google require you to use their payment systems for processing subscriptions on mobile devices, you have more flexibility when it comes to web subscriptions. I chose Stripe because it integrates nicely with RevenueCat and offers relatively low processing fees (2.9% + 30¢ per transaction). This means you can earn more per subscription when users sign up through your website compared to paying the higher fees charged by Apple and Google.

At first, this might make you think, “Oh, I need to drive all of my users to subscribe on the website.” However, there are several reasons not to take that approach. First, both Apple and Google offer “small business” programs that reduce their fees to 15% instead of 30%. Even if you eventually exceed the small business threshold and move to the higher rate, renewal fees drop to 20%.

Second, the more subscriptions you have within a given platform, the more likely that platform is to promote your product in its app store ecosystem. For this reason, I do not try to dictate where users should purchase their subscription.

Wrapping Up, For Now

Setting up the business structure, platform accounts, builds, and subscription systems is a major milestone! There are a million more tips and nuances involved in each of these processes, but I only have so much room in each blog. Hopefully, the insights I shared here will help you avoid some of the pitfalls I fell into along the way and create a smoother path toward getting your website and mobile apps into production.

If you thought we were done after navigating the gauntlet of business setup and technical services required to launch, think again! There is still one major piece left to tackle: marketing. After all, even the best app will struggle to succeed if no one knows it exists.

In Part 4, we will explore topics such as social media, creating videos, providing user support, and engaging with the public.

Pennies-AI officially went to production on January 24th, 2026. Thanks for following along! There’s still a lot more to cover in Part 4.

Product: Pennies-AI
Website: https://www.pennies-ai.com/
Facebook: https://www.facebook.com/PenniesAI
YouTube Tutorials: https://www.youtube.com/@Pennies-AI

Series Note

This post is part of an ongoing series documenting the journey of turning Pennies-AI from an idea into a real, production mobile and web application.

If you’re joining here, you may want to start with the earlier posts in the series. Part 1 explores the foundational architecture and early development decisions that shaped the prototype:

How to Turn an Idea Into an App (Part 1) →

In Part 2, the focus shifts to operating the system in production — including infrastructure trade-offs, reliability considerations, and the real costs involved in keeping a live application running:

Turning a Prototype into a Production App: Architecture, Costs, and Hard Lessons (Part 2) →

This post has focused on navigating the ecosystem required to actually deploy and monetize a mobile app — from business setup and platform accounts to subscriptions and payment providers.

In Part 4, we’ll move beyond deployment and into the next major challenge: helping people discover and use the app.