Building Growth Systems That Scale
Anna Danyi
1 March 20255 min read
Heroic launches feel good in the week they ship. They do not compound. The apps that keep growing are boring in the best way: they have a single source of truth for data, clear owners for acquisition, activation, retention, and revenue, and tooling that lets people experiment without breaking production. That is a growth system — not a campaign calendar.
This piece is the operating view we use when we install systems for clients: three layers (instrumentation, analysis, execution), a ruthless focus on one north-star and one primary funnel first, and a team shape that matches the stack. It pairs with the cultural definition in what is growth engineering and the engagement models on Growth Engine and Scale Partners.
Start with one metric and one funnel
Teams that try to instrument everything on day one usually instrument nothing useful. Pick one north-star metric the business will manage to — contribution payback, D30 retained subscribers, week-four revenue per installer — and one primary funnel that feeds it. Instrument that path end-to-end before you add vanity dashboards.
For consumer apps the economic spine is almost always payback and early ROAS, not "installs." If that sentence feels uncomfortable, read app payback period and what is a good ROAS before you buy another tool. Plug your assumptions into the Payback Engine and ROAS calculator so the system has a number to obey.
Product analytics vendors document the same sequencing idea in different language: define the critical events, then build cohorts and funnels on top. See Amplitude's growth and analytics guides and Mixpanel's product analytics resources for event taxonomy patterns worth stealing. Your job is not to copy their demo workspace; it is to make your activation event trustworthy.
The three layers of a growth system
Instrumentation is identity, events, and attribution you can defend in a finance meeting. If SKAN, MMP, and platform dashboards disagree, document the definition you manage to — window, revenue basis, source of truth — and stop arguing screenshots. Apple's SKAdNetwork documentation is required reading for iOS-heavy mixes; pretending the delay is not there is how kill lines quietly drift.
Analysis is cohorts, funnels, and a weekly reading ritual. Dashboards that nobody opens are decoration. The ritual we care about is closer to the D7 ROAS kill line: pre-commit the threshold, read on schedule, act without theatre. Analysis should change next week's bets, not decorate last month's board pack.
Execution is campaigns, experiments, creative velocity, and automation. This is the layer most teams over-invest in first because it is visible. Without the two layers above, execution is spend with anecdotes. With them, execution becomes a controlled loop: hypothesis → ship → measure → kill or scale. Creative production at volume — including AI creatives — only pays off when the kill criteria exist.
Tooling that enables experiments without breaking production
A scalable system separates "change messaging" from "ship a new binary." Feature flags, remote config, web landing stacks, and store custom pages exist so marketers and growth engineers can test without treating every idea like a release train. Apple's Custom Product Pages are a concrete example on the store side; our CPP guide covers how we use them in UA.
On the web and in-app side, keep experiment surfaces boring and measurable: clear exposure logging, one primary success metric, and a holdout when the change is large. Optimizely's public materials on experimentation and Segment's docs on customer data infrastructure are useful references for how mature stacks think about exposure and identity — even if your stack is smaller.
Also publish internal tools your team will actually open. We keep a public tools shelf for that reason: economics calculators and creative helpers that force shared maths before shared opinions.
Team structure that matches the system
Systems fail when ownership is vague. The shape that scales in most mid-stage app companies is simple: growth engineers who own the stack (events, experiment plumbing, landing and in-app surfaces), growth marketers who own strategy and creative, and a shared language around metrics and weekly decisions. Nobody "owns growth" in the abstract; people own interfaces between layers.
Hire and brief against that map. A media buyer who cannot read a cohort table will optimise the auction to the wrong event. An engineer who refuses to think about hooks will ship perfect plumbing for bad messages. The creative testing framework and how to lower CPI only work when both sides share the kill line.
If you are buying outside help, prefer partners who install the system over partners who rent you activity. That is the difference between agency work that leaves a machine behind and a retainer that disappears when the login is revoked.
A practical build order
1. Freeze the north-star and the primary funnel. 2. Fix event quality and attribution definitions until finance trusts the table. 3. Stand up one weekly ritual with pre-committed thresholds. 4. Open the execution throttle — creatives, landings, onboarding — only as fast as the ritual can digest. 5. Automate repetition last (budgets, creative variants, messaging) once humans trust the loop.
Skip steps and you get the familiar mess: AI generating fifty ads into an unmeasured funnel, or a beautiful Amplitude project that never changes what ships. For the AI-specific version of this argument, see AI-powered growth systems.
If you want help installing the stack rather than another campaign sprint, book a discovery call. Bring your current north-star, your event dictionary, and one screenshot of the dashboard people actually argue about.
Sources & further reading
Anna Danyi
Founder at Exp(G) — building and scaling mobile apps with AI-powered growth systems. About the team