Growth Runtime: An AI Growth Agent for Apps with No Users
Build an AI growth agent that helps an early-stage founder discover, reach, convert, and activate the right first users with evidence, not guessing.
Why this matters
The real problem is not making an app go viral. A founder has built something but does not know which users to target, what message will resonate, which channels to use, or why people drop off after trying it. Random posting wastes the scarce time an early app has. The value is a system that turns growth from guessing into an evidence-based learning loop, and that holds a human approval step before anything reaches a real person.
Persona
Solo founder or small startup with a working app and fewer than 1,000 users
Current manual workflow
The founder posts in scattered places by instinct, guesses at the ideal customer, the channel, and the message, and cannot tell which of those guesses worked or why users drop off after signup.
The AI workflow to build
The copilot runs five jobs over a founder submission. It reads the app, landing page, and any analytics to state what the product does, who it is for, the top segments, the value proposition, and the friction in onboarding. It proposes prioritized user segments and finds channels where those users already gather, with a reason for each. It generates messaging experiments, each tied to a segment, a hypothesis, a channel, and a success metric, and queues outreach for human approval rather than sending it. It inspects where users drop in onboarding and recommends activation fixes. It closes with a weekly memo: what was tested, what worked, and the next experiment. The MVP is a single guided flow; the stretch decomposes the jobs into understanding, segment, channel, messaging, experiment, activation, and guardrail agents.
Inputs
- app URL
- founder notes and the current landing page
- analytics, if available
- existing users or waitlist
- competitor links
- support messages or feedback
Outputs
- prioritized ICP segments with reasons
- a landing-page critique naming friction points
- five growth hypotheses tied to a segment and a metric
- five outreach drafts queued for approval, never sent
- five channel suggestions with evidence
- onboarding and activation fixes
- a weekly experiment plan
Definition of done
On a synthetic founder submission (an app URL, a short description, and a few sample users), the copilot returns at least three prioritized segments each with a stated reason, a landing critique naming concrete friction, five hypotheses each tied to a segment and a success metric, five outreach drafts held for human approval and never sent, five channel suggestions with a reason each, onboarding fixes aimed at activation, and a weekly experiment plan. No message is sent without approval, and every segment and channel carries a reason.
An app submission: a URL for a tool that turns GitHub projects into a shareable portfolio, the description help students show proof of work, current users 40, channels tried random social posts.
Segments: students building portfolios (primary, reason: the tool converts existing GitHub work into proof that job-seeking students need); bootcamp graduates; junior-developer hiring managers. Landing critique: the headline names the feature, not the outcome, and signup asks for too much before the first value. Hypothesis: students do not trust a resume to show skill, message show proof of work not a resume, channel CS Discord servers and university career forums, metric signup rate. Five outreach drafts queued for approval. Onboarding fix: import your first repo as the first step, before account setup. Weekly plan: test segments A and B, hold segment C.
Data plan
public data
Boundaries and non-goals
- sending outreach automatically without human approval
- scraping communities at scale
- guaranteeing users or growth
- real CRM, analytics, or ad-platform integration
- real customer data
Evaluation ideas
- segment believability and the quality of the stated reason
- messaging usefulness and whether each message ties to a hypothesis
- spam avoidance and the presence of an approval gate
- activation improvement, not just acquisition
- clarity of experiment tracking
- could a real founder act on it next week
Run Level target
R3 Reliable Plain translation: handles real cases.
Scope envelope
Buildable by one solo builder in 20 to 30 focused hours, on public, synthetic, or sanitized data, with a demo path that requires no production access.
Suggested tools
- any LLM for reasoning and drafting
- any page-fetch step for landing-page analysis
- a simple table or CRM-style store for experiments and an approval queue
Suggested options, never requirements; briefs are tool-agnostic.
Product thesis questions
- Which is the higher-value wedge for an app with no users, acquisition messaging or activation fixes?
- What evidence threshold should gate a recommended segment before a founder spends time on it?
- Where exactly should the human approval step sit so the loop stays fast but nothing ships unreviewed?