DEV Community: Mostafijur Rahman

I Added One-Time Purchases to My React Native App with RevenueCat — Here's Everything I Wish I Knew

Mostafijur Rahman — Sat, 06 Jun 2026 03:38:11 +0000

Most "in-app purchase" tutorials for React Native assume you want subscriptions. I didn't.

For my app, I wanted something simpler: pay once, unlock Pro forever. No recurring billing, no churn dashboards, no "your trial is ending" emails. Just a clean lifetime unlock.

Turns out, doing this well with RevenueCat in an Expo app has a few sharp edges nobody warned me about. This is the guide I wish I'd had — the actual setup, the code that worked, and the one mistake that cost me an afternoon.

Stack for this guide: React Native + Expo (managed workflow with dev builds), react-native-purchases, RevenueCat dashboard, and Google Play Console.

Why one-time instead of subscription?

I'll be honest — subscriptions make more money on paper. But for the kind of app I was building, a recurring charge felt wrong. People don't want to "subscribe" to a small utility; they want to buy it and move on.

So the model became: a single lifetime Pro purchase. In RevenueCat terms, that means a non-consumable product tied to one entitlement called pro. Get that mental model right and everything else falls into place.

A quick vocabulary check, because mixing these up is where most confusion starts:

Consumable — can be bought repeatedly (coins, power-ups). Not what we want.
Non-consumable — bought once, owned forever (lifetime unlock). This is us.
Subscription — recurring access. Not us either.

If you accidentally configure your lifetime product as a consumable, RevenueCat will treat it as something the user "uses up," and restoring it later gets messy. Set it as non-consumable from day one.

Step 1: Configure the product in Google Play Console

Before touching any code, the product has to exist on the store side.

In Play Console, go to Monetize → Products → In-app products (not Subscriptions — that trips people up). Create a new product:

Product ID: something stable like pro_lifetime. You can't change this later, so pick carefully.
Name & description: what the user sees.
Price: set your launch price.
Activate it.

That's the store-level setup. The product now exists, but your app doesn't know about it yet — that's what RevenueCat connects.

Step 2: Wire up RevenueCat

In the RevenueCat dashboard:

Create a Project and add your Android app with its package name.
Under Entitlements, create one called pro. This is the thing your code checks — "does this user have Pro?"
Under Products, add the pro_lifetime product ID you created in Play Console.
Under Offerings, create a default offering and attach a package containing that product.

The layering feels redundant at first (product → package → offering → entitlement), but it pays off: you can change pricing, swap products, or run experiments later without shipping an app update. Everything is driven from the dashboard.

Step 3: Install the SDK in Expo

npx expo install react-native-purchases

Because this needs native code, you can't run it in Expo Go — you need a development build:

npx expo prebuild
npx expo run:android

If you've never made a dev build before, this is the part that surprises Expo developers. Expo Go won't cut it for IAP. Once your dev build is running, you're ready to initialize.

Step 4: Initialize and fetch offerings

Initialize RevenueCat once, early in your app's lifecycle:

import Purchases from "react-native-purchases";

export function initRevenueCat() {
  Purchases.configure({
    apiKey: "your_google_play_api_key", // from RevenueCat dashboard
  });
}

Then fetch what's available to sell:

async function getOffering() {
  try {
    const offerings = await Purchases.getOfferings();
    const current = offerings.current;

    if (current && current.availablePackages.length > 0) {
      return current.availablePackages[0]; // our lifetime package
    }
  } catch (e) {
    console.error("Failed to fetch offerings:", e);
  }
  return null;
}

Notice you're never hardcoding prices in the app. The price string comes from the store, localized to the user's region automatically. That's one of the quiet wins of going through RevenueCat instead of rolling your own billing.

Step 5: Make the purchase

async function buyPro(pkg) {
  try {
    const { customerInfo } = await Purchases.purchasePackage(pkg);

    if (typeof customerInfo.entitlements.active.pro !== "undefined") {
      // Pro unlocked — update your UI / state here
      return true;
    }
  } catch (e) {
    if (!e.userCancelled) {
      console.error("Purchase failed:", e);
    }
  }
  return false;
}

The key check is customerInfo.entitlements.active.pro. If that entitlement is active, the user owns Pro. Note the e.userCancelled guard — users backing out of the purchase sheet is normal, not an error worth logging.

Step 6: Check entitlement on every launch

A purchase isn't a one-time event you forget about. Every time the app starts, you check whether this user already owns Pro:

async function isPro() {
  try {
    const customerInfo = await Purchases.getCustomerInfo();
    return typeof customerInfo.entitlements.active.pro !== "undefined";
  } catch (e) {
    return false;
  }
}

And give users a Restore Purchases button — this is non-negotiable for non-consumables, and both stores expect it:

async function restore() {
  try {
    const customerInfo = await Purchases.restorePurchases();
    return typeof customerInfo.entitlements.active.pro !== "undefined";
  } catch (e) {
    return false;
  }
}

Without this, a user who reinstalls or switches devices loses access to something they paid for — and you'll get a one-star review for it.

The gotcha that cost me an afternoon

Here's the part the tutorials skip.

When you connect RevenueCat to Google Play, you need to set up a Google Cloud service account so RevenueCat can verify purchases server-side. I hit a "Credentials need attention" warning on the dashboard and went looking for help.

I asked an AI assistant how to fix it. The steps it gave me were confidently wrong — outdated permission names, a flow that didn't match what I was actually seeing in Google Cloud. I burned real time following instructions for a UI that no longer existed.

What actually fixed it: going to RevenueCat's own documentation and following their service-account setup step by step. The official docs matched the current Google Cloud console exactly, and the warning cleared.

The lesson isn't "AI is useless" — I use it constantly. The lesson is that for platform setup that changes frequently (cloud consoles, billing permissions, store configs), the vendor's own docs are the source of truth. AI training data lags behind these UIs by months, and IAP plumbing is exactly the kind of thing that gets reorganized often.

If you hit the credentials warning: don't improvise, don't trust a generic answer. Open the RevenueCat docs page for Google service account setup and follow it line by line.

A few smaller things I learned

Sandbox testing works before credentials are fully green. The "Credentials need attention" warning didn't block me from testing purchases in sandbox, which is why it's easy to ignore — right up until you go to production.
Use a real test account added in Play Console's license testing, not your developer account, to test the full purchase flow.
Don't hardcode the price anywhere in your UI. Read it from the package. Saves you a release when you change pricing.

Wrapping up

A one-time lifetime purchase in React Native comes down to four things: configure a non-consumable product, map it to a pro entitlement in RevenueCat, drive the purchase from offerings, and check the entitlement on launch. The SDK does the heavy lifting.

The only part that genuinely tripped me up was the Google Cloud credentials linking — and the fix there was simply trusting the official docs over a confident-but-stale answer. If you're building something similar, that's the hour I'd save you.

I Thought Domain-Driven Design Was a Waste of Time. I Was Wrong.

Mostafijur Rahman — Fri, 22 May 2026 10:33:11 +0000

The first time someone explained Domain-Driven Design (DDD) to me, I thought it was a lot of ceremony for very little payoff.

Aggregates, value objects, bounded contexts — a whole vocabulary to learn. I had shipped plenty of features without any of it. My honest assumption: this will just slow me down.

I was wrong. Here's the short version of how I found out.

The project that changed my mind

I worked on a system with a hierarchy — Site, then Aggregator, then a unit under that. A "plan" existed at every level.

In the code, all three were just plan. Same name, same shared object, everywhere.

It worked — until it didn't. Features started colliding. A change to one level's plan quietly broke another. Every function needed a comment explaining which plan it meant. New people asked the same question every week: "is this the site plan or the unit plan?"

The code ran fine. The understanding around it was rotting.

That's the exact problem DDD is built to fix.

What DDD actually is

DDD is not a framework. Nothing to install. It's a discipline: design your software around the business problem, not the database or the framework.

The patterns get all the attention, but the real value is in two boring ideas.

1. Ubiquitous language — name things honestly

Pick precise words and use them everywhere — in conversations, tickets, and the code itself.

If the business has a "draft plan" and a "submitted plan," those exact words belong in your class names. Not plan with a vague status field. The moment a name is vague, logic starts hiding inside it.

My entire mess traced back to one overloaded word.

2. Bounded context — stop forcing one model

"Customer" means different things to billing, support, and analytics. Forcing one shared Customer class gives you 40 fields nobody dares touch.

A bounded context is a line you draw: inside this boundary, a word means exactly one thing. Cross the line, you're allowed a different model.

This is also the most reliable way to answer "how do I split this microservice?" — split where the domain actually splits.

The patterns, in one line each

Entity — has a stable identity over time (an order stays that order).
Value object — defined only by its values (money, a date range).
Aggregate — a group of objects with one entry point that enforces the rules.
Repository — hides how data is stored from your domain code.
Domain event — something meaningful happened (PlanSubmitted).

But these only make sense after the language and boundary work. Reach for them first and you get fancy code that models nothing real.

When to skip DDD

My old skepticism wasn't wrong — just aimed at the wrong project.

Skip DDD if: the app is simple CRUD, the project is small or short-lived, or the complexity is technical (algorithms, performance) rather than business logic.

Use DDD if: the domain is genuinely complex and the software has to live and evolve for years.

"This will slow me down" is correct — for simple projects. It's completely wrong for complex ones.

What I'd tell my earlier self

The patterns are not the point. You can memorize aggregates and value objects and still build a mess.

The point is the boring stuff: talk to the people who understand the business, agree on exact words, draw honest boundaries, and let the code follow.

DDD is overhead. On a simple project, bad trade. On a complex one meant to last, it's the cheapest insurance you'll ever buy.

Originally published on mrsajib.com. I write weekly about backend engineering and building software that lasts.

AI Will Replace Backend Developers? A Python Engineer's Honest Take

Mostafijur Rahman — Thu, 07 May 2026 16:29:47 +0000

Everyone is talking about AI replacing developers.

Some people are scared. Some people laugh it off. Most people just don't know what to believe.

I've been a backend engineer for 6 years. I write Python every day. I build APIs, real-time systems, and production backends. And honestly? I was worried too — until I actually started paying attention to what's happening on the ground.

Let me share what I've seen. No hype. No fear. Just real experience.

Yes, I Use AI Tools Every Day

I'm not going to pretend I don't use AI. I use GitHub Copilot and Claude Code daily.

They help me move faster. Repetitive tasks that used to take 30 minutes now take 5. Boilerplate code, basic CRUD, writing tests — AI handles these really well.

But here's the thing I noticed early on:

I never just trust what AI gives me.

Every single time, I review it. I test it. I make sure it actually fits the system I'm building — not just some generic example from the internet. Because AI doesn't know my system. Only I do.

That one habit — reviewing AI output instead of blindly copying it — is what separates engineers who grow with AI from those who get burned by it.

The Night My Production API Crashed

Let me tell you about a night I'll never forget.

It was around 2 AM. My client messaged me — the server was down. Production. Real users. Real impact.

I jumped on my laptop immediately.

I checked the logs. Dug through the errors. And there it was — a concurrency bug. Multiple requests were hitting the same database row at the same time, causing a race condition that Django wasn't handling cleanly.

I fixed it using select_for_update() — a database-level lock that made sure only one request could modify that row at a time. Crisis over.

Now here's my question:

Could AI have fixed that at 2 AM?

Maybe AI could have suggested select_for_update() if I described the problem perfectly. But finding the problem in the first place? Understanding why that specific bug was happening in that specific system under that specific load? That took 6 years of experience. That took knowing the codebase. That took staying calm under pressure and thinking clearly when everything is on fire.

No AI tool was going to wake up and fix that for my client. I was.

What AI Actually Cannot Do

After 6 years of real production work, here is what I have learned AI genuinely struggles with:

Understanding your business context

When I build a system, I need to understand why it needs to work a certain way — not just how. AI doesn't sit in client meetings. It doesn't ask the right questions. It doesn't know that your client's team works across time zones and needs very specific workflows.

Making architecture decisions

PostgreSQL or DynamoDB? Microservice or monolith? WebSocket or polling? These decisions have consequences that last years. They depend on team size, budget, and where the product is going. AI can give you options — but it cannot make the right call for your specific situation.

Debugging complex production issues

Race conditions. Memory leaks. Concurrency bugs at 2 AM. These are not problems you solve by copy-pasting into ChatGPT. They need deep system knowledge, real experience, and sometimes — a lot of patience when everything is breaking at once.

Taking responsibility

When production breaks, someone has to own it. Lead the fix. Talk to the client. Make sure it never happens again. AI tools have zero accountability. They cannot be on-call. They cannot look a client in the eye and say "I've got this."

So What Is Really Happening?

Here is my honest take:

AI is not replacing backend developers. It is replacing developers who refuse to grow.

Developers who only write basic APIs with no systems thinking? They will struggle.

Developers who understand distributed systems, concurrency, data modeling, and business logic — and also know how to use AI tools effectively? They are becoming more valuable than ever.

The data backs this up. Software engineering job postings in 2026 are at a 3-year high. Companies are not hiring fewer engineers — they are hiring better ones.

The Real Danger Is Not AI

The real danger is staying the same while everything around you changes.

If you are still writing the same code the same way you did 3 years ago — that is the actual threat to your career.

The engineers winning right now are the ones who:

Use AI to move faster — not as a replacement for thinking
Build deep expertise in systems design and architecture
Understand the business, not just the code
Communicate clearly when things go wrong
Never stop learning

My Honest Advice

Use AI tools. Use them every day. But never stop building your own depth.

Because the day a really hard bug hits production at 2 AM — your client is not going to call ChatGPT.

They are going to call you.

Make sure you are ready to answer.

By Mostafijur Rahman — Backend Engineer

Originally published at mrsajib.com

Securing Your Django Application: Best Practices for Preventing XSS, CSRF, and More

Mostafijur Rahman — Wed, 25 Sep 2024 16:20:18 +0000

Security should always be at the forefront of any web development project. With Django, you get a framework that provides a lot of built-in security features, but there are still steps you must take to ensure your application is secure. In this post, we'll explore some best practices for preventing common web vulnerabilities such as Cross-Site Scripting (XSS), SQL Injection, Cross-Site Request Forgery (CSRF), and more.

1. XSS Injection and HTML Injection Prevention

Cross-site scripting (XSS) attacks occur when malicious scripts are injected into websites, typically via user input fields. To prevent XSS, you must sanitize all user input by removing dangerous tags, attributes, and scripts. The bleach library was traditionally used for sanitizing input, but it has been deprecated since 2023. A great alternative is html-sanitizer, which can effectively sanitize user input.

In addition to sanitizing input, you should leverage Django's built-in escape filters within templates. These filters ensure that user-generated content is safely escaped, preventing dangerous HTML from rendering.

Be cautious when using Django template tags like is_safe, safe, mark_safe, and especially when auto escaping is turned off. These tools bypass the default escaping mechanisms and should only be used when absolutely necessary.

Implement a Content Security Policy (CSP)
Another layer of protection is to add a Content Security Policy (CSP) to your HTTP headers. A CSP limits which sources are allowed to load content on your site, reducing the risk of XSS attacks. You can implement CSP in Django using middleware like django-csp.

2. Cross-Site Request Forgery (CSRF) Protection

Django provides built-in protection against Cross-Site Request Forgery (CSRF) attacks. This is achieved by ensuring that any form submissions include a secret, user-specific token. When using HTTPS, this protection is further enhanced by verifying the Referer header for same-origin requests.

Avoid Disabling CSRF
While Django allows you to disable CSRF protection for specific views using the @csrf_exempt decorator, be very cautious when doing so. Disabling CSRF protection exposes your application to significant risks. Always prioritize the use of HTTPS and consider enforcing HTTP Strict Transport Security (HSTS) for an additional layer of protection.

3. SQL Injection Protection

Django is well-equipped to handle SQL injection attacks by using parameterized queries. When you work with Django's ORM, user input is automatically escaped, preventing SQL injection vulnerabilities.

However, when you manually execute raw SQL queries using methods like RawSQL or extra(), you must ensure that user-controlled inputs are properly sanitized and escaped. If you are ever in doubt, it's safer to use Django's ORM methods.

4. Clickjacking Protection

Clickjacking is a sneaky attack where a malicious actor hijacks legitimate clicks and routes them to hidden, malicious pages. For instance, a user might think they're clicking a button on a legitimate site, but their clicks are being intercepted by an invisible iframe.

Django provides X-Frame-Options middleware to prevent your site from being embedded within an iframe. This middleware ensures that your site cannot be framed, offering effective protection against clickjacking attacks.

5. Securing Django Sessions

Django sessions are a way to store user-specific data, such as login status. Misconfigured session settings can lead to session hijacking or session fixation attacks. Here are a few key configurations to secure your sessions:

Secure Session Cookies: Ensure session cookies are only transmitted over HTTPS.

SESSION_COOKIE_SECURE = True

HTTPOnly: Prevent JavaScript from accessing session cookies by setting the HttpOnly flag.

SESSION_COOKIE_HTTPONLY = True

Session Expiry: Set a session expiry time to minimize risk.

SESSION_COOKIE_AGE = 1209600  # Two weeks in seconds

6. Man-in-the-Middle Attacks (SSL/TLS)

To protect your users' data from Man-in-the-Middle (MITM) attacks, it's crucial to use encryption via HTTPS. Django can be configured to automatically redirect all HTTP traffic to HTTPS:

SECURE_SSL_REDIRECT = True

You should also enable HTTP Strict Transport Security (HSTS), which ensures that browsers only communicate with your site over HTTPS in the future:

SECURE_HSTS_SECONDS = 31536000  # 1 year
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True

7. Leverage Django's Built-in Security Checklist

Django provides a built-in security checklist that you can run to ensure your project meets security guidelines. This command will scan your settings.py file and provide warnings if you have any misconfigurations that could expose your application to security risks:

python manage.py check --deploy

Make sure to review any warnings or errors and adjust your settings accordingly.

Conclusion

Django offers a robust set of tools and best practices for securing your application. By following the guidelines outlined above, you can significantly reduce the risk of attacks such as XSS, CSRF, SQL injection, and more. Remember, security is not a one-time task—it's an ongoing process of monitoring, patching, and improving.