04 Services
Subscription plumbing that reconciles: StoreKit and Adapty wired to your backend, webhooks that do not silently drop a renewal, and paywalls tested against live traffic instead of opinion. Trials, family plans, referrals and win-backs included.
A subscription is not a screen, it is a ledger. StoreKit takes the money, the store sends events about it, and your database has to agree with both. The moment those three disagree, a paying customer loses access or a cancelled one keeps it, and you find out from a support email rather than a dashboard.
We run StoreKit with Adapty across the paid apps in this portfolio: purchase and restore on the phone, receipts and webhooks verified server-side, and reconciliation so that a renewal arriving while the app is closed still lands in the database. Trials are where this breaks quietly — a trial start is not revenue, and any app that reports it as revenue will hand you numbers you cannot use to make a decision.
Then there is the paywall itself, which is a product surface rather than a decoration. We build variants and test them on live traffic, because the price, the plan that is preselected and the first line of copy move conversion more than anything else on that screen.
Free to download with a subscription behind it, wired through StoreKit and Adapty and reconciled against the same backend that holds the user's food log. It has been running that way since November 2024, which is long enough to have been through OS releases, store policy changes and the ordinary mess of real renewals.
Bite AIOrder Fit launched in January 2026 on the same stack: purchase and restore on the phone, receipts and webhooks verified on the server, and the entitlement written where the rest of the app can read it without asking Apple again. It holds 4.6 stars from 222 ratings.
Order FitStore events arrive when the app is closed, out of order, and sometimes twice. They are handled server-side and written idempotently, so the database lands in the same state regardless of how the event got there — and an event that fails is visible instead of gone.
Which plan is preselected, what the first line says, whether the trial is named in the button: all testable, none worth settling in a meeting. Variants run against real users, one change at a time, and the output is a trial-to-paid funnel you can actually read.
Which parts of the app are free, where the wall sits, and what a trial includes. It is a product decision and it gets made before any code.
StoreKit or Adapty on the phone: purchase, restore, and an entitlement check the rest of the app can rely on without special cases.
Receipts verified and webhooks handled server-side, written so a repeated event is harmless, so the store, the database and the app agree.
Trial starts, trial-to-paid, renewals and cancellations, reported in a form that survives being checked against App Store Connect.
Variants on live traffic, one change at a time, with the losing variant removed rather than left running quietly forever.
A paragraph about the app, the feature or the thing that is stuck is enough, plus roughly when you need it and the budget range you are working with. One piece of this on its own is fine, and so is the whole thing. Our team reads every message and answers, usually within one business day.