Subscriptions that reconcile across App Store, Play and web by Sevastian RakhimovSubscriptions that reconcile across App Store, Play and web by Sevastian Rakhimov
Subscriptions that reconcile across App Store, Play and webSevastian Rakhimov

The question your product has to answer correctly

Is this person paid right now?
It sounds trivial until the money arrives from more than one place. The App Store knows about its own subscribers. Google Play knows about its own. A web checkout knows about a third group. None of them tell each other anything — and a user who paid on your website opens the iOS app expecting it to already know.
Get it wrong one way and paying customers are locked out and ask for refunds. Get it wrong the other way and you give the product away for free and never find out, because nothing errors. Revenue is simply lower than it should be and no dashboard says why.

What I build

One source of truth for entitlement. Every surface of your product asks the same question in the same place, instead of each one guessing from whichever receipt it happens to hold. RevenueCat where it fits, a direct implementation where it does not.
Web billing alongside the stores. A checkout outside the app stores, wired into the same entitlement model, so a web subscriber is indistinguishable from a store subscriber everywhere inside the product.
Webhooks handled properly. Renewals, cancellations, refunds, grace periods, billing retries, upgrades and downgrades arrive asynchronously and out of order. Every handler idempotent, because stores redeliver. Every event logged, because in six months somebody will ask what happened to one specific account.
Restores that restore. New phone, reinstall, changed account, family sharing — the paths real users take that never appear in a happy-path test.
Reconciliation and alerting. A scheduled check that what the stores report, what the billing provider reports and what your database believes all agree, with an alert when they diverge. This is the part almost everyone skips, and it is the part that finds the silent leaks.

Why me

I run this in production. F/AI, the AI fitness trainer I co-founded and run as CTO, takes money through the App Store, Google Play and a separate web checkout at the same time: 2,000+ active paid subscriptions and $8,000 MRR that reconciles across all three.
It is a narrow skill with very little competition, because it is not fun work. It is also the difference between a product that earns and a product that almost earns.

How we work

Fixed price against a written scope after I have seen your setup. I work in your accounts with your keys. You get a runbook at the end: what each webhook does, what to check when a customer disputes their subscription, and what the reconciliation alert means when it fires.
FAQs

Starting at$3,000
Tags
Flutter
PostgreSQL
RevenueCat
Stripe
Backend Engineer
iOS Developer
Mobile Engineer
Software Engineer
In-App Purchases
Subscriptions
Service provided by
Sevastian Rakhimov Tbilisi, Georgia
2
Followers
Subscriptions that reconcile across App Store, Play and webSevastian Rakhimov
Starting at$3,000
Tags
Flutter
PostgreSQL
RevenueCat
Stripe
Backend Engineer
iOS Developer
Mobile Engineer
Software Engineer
In-App Purchases
Subscriptions

The question your product has to answer correctly

Is this person paid right now?
It sounds trivial until the money arrives from more than one place. The App Store knows about its own subscribers. Google Play knows about its own. A web checkout knows about a third group. None of them tell each other anything — and a user who paid on your website opens the iOS app expecting it to already know.
Get it wrong one way and paying customers are locked out and ask for refunds. Get it wrong the other way and you give the product away for free and never find out, because nothing errors. Revenue is simply lower than it should be and no dashboard says why.

What I build

One source of truth for entitlement. Every surface of your product asks the same question in the same place, instead of each one guessing from whichever receipt it happens to hold. RevenueCat where it fits, a direct implementation where it does not.
Web billing alongside the stores. A checkout outside the app stores, wired into the same entitlement model, so a web subscriber is indistinguishable from a store subscriber everywhere inside the product.
Webhooks handled properly. Renewals, cancellations, refunds, grace periods, billing retries, upgrades and downgrades arrive asynchronously and out of order. Every handler idempotent, because stores redeliver. Every event logged, because in six months somebody will ask what happened to one specific account.
Restores that restore. New phone, reinstall, changed account, family sharing — the paths real users take that never appear in a happy-path test.
Reconciliation and alerting. A scheduled check that what the stores report, what the billing provider reports and what your database believes all agree, with an alert when they diverge. This is the part almost everyone skips, and it is the part that finds the silent leaks.

Why me

I run this in production. F/AI, the AI fitness trainer I co-founded and run as CTO, takes money through the App Store, Google Play and a separate web checkout at the same time: 2,000+ active paid subscriptions and $8,000 MRR that reconciles across all three.
It is a narrow skill with very little competition, because it is not fun work. It is also the difference between a product that earns and a product that almost earns.

How we work

Fixed price against a written scope after I have seen your setup. I work in your accounts with your keys. You get a runbook at the end: what each webhook does, what to check when a customer disputes their subscription, and what the reconciliation alert means when it fires.
FAQs

$3,000