Less growth-team tickets. More roadmap shipped.
You've vetoed tools like this before, probably correctly: webview paywalls, SDK bloat, a "marketing platform" that broke the build on a Friday. This page is the case for the exception — written to be verified, not believed. Every claim below has a docs page behind it; if your team can't confirm it in ten minutes, that's our bug.
AppDNA is the App Growth OS for subscription apps; for engineering leaders it is the one SDK that takes growth surfaces out of the release train: paywalls, onboarding flows, messages, and surveys render natively (SwiftUI on iOS, Jetpack Compose on Android — not webviews) from server-side configuration, behind a safety model — approval-gated changes, staged rollouts, KPI stop-losses, instant rollback, full audit trail — designed to be reviewed like infrastructure, not marketing.
Five ways growth work lands on engineering — and how each one disappears.
The sprint that wasn't yours
Ravi runs mobile. Sprint 14's commitments: offline mode and the payments migration. Sprint 14's actual output: two paywall variants for growth, an expedited-review request for a mispriced test, and a rollback release built at 11pm Thursday. The retro says "protect the roadmap." The backlog says six more growth tickets are waiting.
One team. Two masters. The roadmap loses politely, every sprint.
Ravi's team installed the SDK back in sprint 11 — one story, under an hour, one placement call reviewed like any dependency. Growth changes ship from the growth team's console now: approval-gated on their side, staged from 10% of traffic, stop-losses armed, rollback a server action nobody pages engineering for. Sprint 14 shipped offline mode and the payments migration. Growth shipped seven experiments the same fortnight. Neither asked the other's permission.
Same team. One SDK. The roadmap is engineering's again.
What you're actually adopting
The SDK — one dependency, native rendering, bounded behavior.
iOS, Android, Flutter, and React Native. Renders paywalls, onboarding, messages, and surveys as SwiftUI and Jetpack Compose views from server-side configuration — no webviews on the money path. Installed in under an hour: initialization plus placement calls. Offline, it falls back to the last known-good cached configuration — no network means no change, never a blank screen.
import AppDNA
AppDNA.configure(apiKey: "appdna_live_…")
AppDNA.present(placement: .onboardingComplete)The safety model — read it like a design doc, because it is one.
Every write is approval-gated by a named human and audit-logged. Rollouts stage from 10% of traffic; a KPI stop-loss halts and withdraws anything that hurts a guarded metric; rollback is instant and server-side; SRM detection catches broken splits before they masquerade as results; destructive actions are deny-listed; auto-mode is an explicit opt-in inside guardrails with hard cost caps. The agents watch, diagnose, and draft — they never ship anything a human didn't approve. It's the change-management system you'd spec for an internal tool, already built and documented in docs.appdna.ai — "what changed, when, and who said yes" is always a query away.
What engineering never does again.
Rebuild the paywall screen. Carry a price test on the release train. File an expedited-review request for a growth mistake. Cut a rollback release at night. Maintain the internal config service someone started two years ago. Answer "can we change the trial length without a release?" — the answer is now structurally yes, and nobody needs to ask you.
What we still need you for — the honest list.
- about an hour, once — initialization plus a placement call wherever a growth surface may appear. A genuinely new surface area needs its placement shipped once, in a normal release; after that it's configuration forever.
- events you don't already send have to be added — or connected from Firebase, Amplitude, RevenueCat and the rest, where zero migration applies.
- AppDNA changes growth surfaces — paywalls, onboarding, messages, surveys. New product functionality is still your roadmap. The point isn't removing engineering from the app; it's removing everything except the product from your queue.
- major versions ride your normal release cadence like any dependency. Growth changes never wait for them.
- we expect your security and App Review assessment, and the docs are written for it. Ten minutes to verify or it's our bug — tell us.
You could build this. That's exactly why you're the veto.
A config-driven native rendering service with an experiments engine is a genuinely fun design doc, and your team could write it. Here's the honest cost of the second 80%:
| Build it in-house | AppDNA | |
|---|---|---|
| Time to first experiment | Quarters of platform work before the first test ships — config service, native renderers on two platforms, targeting, stats engine, admin UI | SDK in under an hour; first experiment live within 14 days |
| The stats engine | SRM detection, guardrail metrics, staged rollouts, stop-loss — each one a project competing with your actual roadmap | Built in, already argued about, already tested |
| Maintenance | Yours forever — every OS release, every StoreKit change, every renderer regression. Industry research: maintaining self-built code runs 17–30% of build cost annually (Gartner, as cited) | Ours. Your engineers stay on the product |
| Odds | Industry research: in-house AI builds succeed 22% of the time; buy/partner, 67% | The 67% path — plus category benchmarks and 80+ encoded playbooks no internal build starts with |
The experiment infrastructure is the same for every app — undifferentiated heavy lifting. Spend your engineers on what only your app can do.
Complete on its own. Compatible with everything you already run.
RevenueCat · Adapty · Firebase · AppsFlyer · Adjust · Amplitude · Mixpanel · Braze · OneSignal
Zero migration. AppDNA reads billing and events from your existing stack on day one — your instrumentation investment carries over, nothing gets rebuilt.
A note from the founder
Due diligence costs two minutes and zero code.
Paste your App Store or Google Play link. The audit reads your public listing and a short set of questions — no SDK, no OAuth, no access, nothing for your security review to review — and returns a Growth Score, the biggest funnel leak, and a 90-day plan. If the plan isn't worth an hour of integration, don't spend the hour.
FAQ
Eight questions CTOs and mobile leads ask us — usually as a checklist, in this order.
01What happens when an experiment misbehaves in production — and who gets paged?
Nobody on your team, by design. Experiments launch at 10% of traffic with a KPI stop-loss that halts and withdraws anything hurting a guarded metric — automatically, without a human in the loop at 2am. Rollback is a server action, instant; devices that are offline keep rendering the last known-good configuration. Every state change is audit-logged. Growth changes stop being an on-call category for engineering, because un-shipping one never requires a release.
02We already run Firebase Remote Config and a feature-flag service. Where does this fit?
Keep them — zero migration, and AppDNA reads your existing stack from day one. Flags toggle code you already shipped; AppDNA renders new native surfaces — paywalls, onboarding flows, messages — from server-side configuration, proposes the experiments from full-funnel data, and carries results into Growth Memory. Run them side by side; consolidate on your renewal calendar if it ever makes sense.
03What's the real API surface — what are we actually integrating?
Initialization plus placement calls — public APIs only, no swizzling, no private frameworks, no reflection tricks. Typical install is under an hour, and the quickstart is public, so your team can scope the work before anyone talks to us. After install, growth changes generate zero engineering work: no releases, no review cycles, no tickets.
04What leaves the device — exactly?
Two flows, both documented in the data schema in the docs: configuration comes down (what to render, to whom); the events you chose to instrument go up, into your isolated workspace. Isolation is enforced in code — your data never trains a shared model and is never visible to another tenant; benchmarks you see are anonymized aggregates. For stricter requirements: dedicated single-tenant deployment, your keys, your SSO — scoped engagements.
05We're a large app with a strict release process and a real security review. Is this built for that?
That's the environment the safety model is shaped for: approval gates map onto your change-management policy, the audit trail feeds your review, staged rollouts respect your risk posture, and dedicated deployment options exist where compliance needs them. Honest exclusions hold at any scale: pure-IAP game economies aren't the fit — this is built for subscription funnels.
06Vendor risk: if AppDNA disappears — or we leave — what breaks?
Nothing at runtime. The SDK's failure mode is the last known-good configuration: your app keeps rendering its most recent approved state with no network dependency on us for correctness. Leaving is symmetric to arriving — deactivate by configuration, remove the dependency in a normal release, revoke tokens, export everything: strategies, experiment history, Growth Memory. No dark-pattern lock-in; exit is a documented path, not a negotiation.
07What does the SDK cost us in binary size and startup time?
It's engineered to stay out of both conversations: rendering uses the platform's own UI frameworks rather than shipping one, and initialization is designed to be off the critical startup path. Exact measured numbers live in the docs — we'd rather you check them than trust an adjective.
08Who operates this day to day — does engineering end up owning another system?
No. Growth owns the operation — proposals, approvals, experiments, journeys — from the console. Engineering owns exactly one artifact: the SDK dependency, updated on your normal release cadence like any other. The audit trail is visible to both, so when someone asks "what changed on the paywall last Tuesday," the answer doesn't route through your team.
Missing your question? Ask us directly — a human replies within one business day. Send the hard ones — and the docs answer most of this in more depth. Read the docs → docs.appdna.ai
Missing your question? Ask us directly — a human replies within one business day. Send the hard ones — and the docs answer most of this in more depth. Read the docs → docs.appdna.ai
See your biggest leak — free, in about 2 minutes.
Everything your app needs to grow. In one system.