Growth Engineering Experiments
I built the growth stack (waitlist, surveys, drip sequences, free-forever grants) and even the free cohort didn't show up. Here's the instrumentation story.
Published
Growth Infrastructure Cannot Manufacture Habit
A case study for what I learned trying. Four months of growth engineering across waitlist, surveys, drips, consent, and free-forever grants. What each piece was supposed to do, what each piece actually did, and the lesson I would take into the next product.
Opening
This is the twin of the post-mortem. The post-mortem tells the story of behavior: people identified the pain, said it was real, and even with the price gate removed did not reliably show up. This case study is the part where I tried to fix that with infrastructure, and discovered that infrastructure is not the lever.
That is the thesis in one sentence: growth infrastructure cannot manufacture habit. If the habit is there, infrastructure amplifies it. If the habit is thin, infrastructure measures the thinness with very high precision. Pricing experiments are the visible failure inside that frame. Behavior is the deeper one.
I built a lot of infrastructure.
The shape of the growth stack
Five layers, each with a job.
- Top of funnel — a waitlist on the marketing site, fed by LinkedIn posts, with a short survey to qualify intent. Admit users in waves.
- Activation — drip tips, onboarding reminders, and progress nudges, sent to bring people back on day two, three, and seven.
- Virality — referral codes with two-sided extensions, scaffolded into the billing path but never deployed to users.
- Goodwill — free-forever grants for early users who stayed engaged through rough edges. Gratitude as an entitlement.
- Compliance — a marketing email consent system with tokenized unsubscribe and per-topic preferences, in place before any marketing email got sent.
Underneath: a transactional email pipeline (queue → cron → delivery → telemetry) shared by all four user-facing layers, with the platform caveats covered in Solo Architecture.
That is more growth machinery than most pre-launch products carry. The shape is intentional in some places, premature in others. The case study is about which was which.
What each piece was actually for
The honest version of why I built each layer. None of it was generic “growth hacking.” Each piece had a real reason that made sense at the time.
Waitlist + survey
Two jobs at once: get the name olllo in front of people through LinkedIn marketing, and control the rate at which they entered the beta. I wanted to admit users in waves, because if there was a problem (a bug, a thin feature, an onboarding rough edge), I would rather hit it on twenty users than on two hundred. The waitlist was a safety mechanism as much as a marketing one.
The survey on the waitlist replaced an earlier Typeform setup. Bringing it in-app meant the responses landed in the same database as the rest of the user data, so I could correlate “what someone said on the survey” with “what they actually did once admitted.”
Free-forever grants
Not a pricing experiment. A thank-you to the early users who provided feedback, helped surface unknown technical issues, and stayed engaged through rough edges. The grant system was deliberate gratitude, encoded as an entitlement that would persist even after I shut the product down.
Drip tips + onboarding reminders
Celebration and continuation. Each tip was framed around progress the user had made, with a reason to come back and a reminder of why the next step mattered. Not aggressive re-engagement, not manufactured urgency. Closer to what I would have written by hand if I had been emailing each beta user individually.
Marketing email consent
Compliance from day one. Tokenized unsubscribe links signed with JWT, per-topic preferences, an audit trail of consent events. I built this before any marketing email got sent, because I never wanted to be in the position of retrofitting compliance after a campaign had already gone out.
What the data actually showed
The infrastructure worked. The metrics did not.
Top of funnel filled the way LinkedIn-driven waitlists usually do, in ones and twos:
| Top of funnel | Count |
|---|---|
| Waitlist signups | 30 |
| Survey completions | 14 |
From the thirty on the waitlist, I split admissions into two cohorts to learn something about the price gate. Ten were granted accounts with no payment step. Twenty were given a Stripe subscription path that required a credit card up front, in exchange for the beta plan: a 60-day free trial then $48/year (50% off the $96/year retail), with two extra months free on the annual plan.
| Activation | Cohort A — no payment (n=10) | Cohort B — Stripe gate (n=20) |
|---|---|---|
| Account created | 9 | 2 |
| Onboarding completed | 5 | 0 |
| Active at 1 month (4+ weekly logs) | 3 | 0 |
| Paid conversion | n/a | 0 |
Two readings sit on top of each other.
The credit-card gate was a hard wall. Eighteen of twenty users never finished account setup, and the two who did finish failed onboarding. The deal on offer was generous (60-day free trial, $48/year at 50% off retail, two more months free on annual), and it did not matter. Asking for a credit card before a user has done anything in the product is asking the user to commit before they have a reason to.
The free cohort surfaced the deeper signal. With the payment friction removed, the funnel still narrowed: half dropped at onboarding, seven of ten had stopped logging by week four. The daily-capture habit did not form for most of the cohort that articulated the pain most clearly — and that is the same shape fitness apps and weight-loss apps live with: a population that names the goal correctly and does not reliably show up to do the work. It is the signal the post-mortem leans on.
Cohort A. With the payment friction removed, the funnel still narrowed: 9 of 10 created accounts, 5 of 10 onboarded, 3 of 10 still logging weekly at week four. Even free, the habit didn’t form for most of the cohort that named the pain most clearly.
By layer, the same pattern shows up everywhere infrastructure was supposed to do the lifting:
Each layer worked. Each layer also failed to produce the outcome it was built for.
The instrumentation surfaces the conclusion cleanly, which is what good instrumentation is supposed to do. The growth stack did its job. Its job was to measure, and the measurement was not what I wanted it to be.
The order of operations was wrong
The chronology of what shipped is the part of this case study I would change if I were doing it again.
The features shipped in roughly this order across the back half of the project:
- Late January: referrals scaffolded into the Stripe billing feature (never operationalized)
- Late January: marketing email consent system
- Early February: drip tip system + onboarding reminder emails
- Late March: free-forever grant migration
- Late March: in-app waitlist survey, replacing the earlier Typeform
Read that list against what each piece is supposed to do, and the inversion is visible. I built virality scaffolding (referrals) and compliance (consent) early, then activation (drips, reminders), and shipped the waitlist survey near the end — the piece that should have come first to tell me whether to build the rest came last.
The order I shipped reflects what was easy to build at each moment, not what would have validated demand fastest. Referrals were a natural extension of the Stripe billing work, so they came when billing did. Compliance was a clean self-contained project. Drips required content and scheduling infrastructure, which took longer to set up. The waitlist survey came late because the Typeform version had been good enough to delay the migration.
A more disciplined order would have started with activation. If new users were not coming back on day two, none of the other layers were going to help.
What shipped versus what I would ship next time. The next-time ordering puts activation first; virality only earns its slot after the curve bends without help.
What I would do differently
The next time I build a product like this, I would not invest in scale-up infrastructure until I had verified, hands-on, that the product was meeting users’ needs and that the early audience was generating organic word-of-mouth without my help.
Concretely, that means:
- Running the first ten or twenty users through the product manually, in close one-on-one observation, before any drip system gets built
- Driving week-over-week adoption through that hands-on attention until the curve bends without me touching it
- Only then investing in the scale machinery (drips, waitlists, surveys, and virality after the curve bends) that would let me step back
Growth infrastructure is a multiplier. Applied to zero demand it produces zero growth; applied to a real signal it compounds. The mistake I made was reaching for the multiplier before the signal was there.
The cleanest version of this lesson, the one I would tell another founder who asked: measure with people first, instrumentation second. Fifteen-minute calls with the first cohort tell you more in a week than a drip system tells you in three months. The instrumentation has its place, but not before the calls.
What I would defend
The compliance-first instinct.
Most products build the marketing system, run a campaign, and then bolt on consent management once the legal requirement gets noticed or once a user complaint surfaces. I built the consent system before the campaign system, with tokenized unsubscribe and per-topic preferences in place from the first marketing email I ever sent. The audit trail of consent events meant I could prove, for any subscriber, when they opted in and to what.
That work was invisible to users (which is exactly what compliance work should be) and would have saved me a hard problem if olllo had ever scaled to a place where data subject requests started arriving. It was also cheap to do up front and expensive to retrofit. The instinct to build compliance before need is one I would carry into every product going forward.
The three compliance primitives that were in place before the first marketing email got sent. Each was cheap to build day-one and expensive to retrofit later.
The honest takeaway
Growth infrastructure measures and amplifies. It does not generate the underlying habit. The temptation in solo building is to mistake the act of building growth machinery for the act of growing, because the machinery is concrete and visible while the underlying habit is abstract and uncomfortable.
Growth = signal × infrastructure. Multiply five layers by zero and you still get zero, instrumented precisely.
I felt that temptation. Every drip email I shipped felt like progress. Every referral mechanic felt like traction. Every survey response felt like signal. None of it was wrong, and none of it was the bottleneck.
The bottleneck was upstream. The post-mortem covers what was upstream and what it taught me. This case study is the instrumentation that surfaced the conclusion. Without the growth stack, I would have taken longer to read the demand signal accurately. With the growth stack, the read was unambiguous, and the decision to stop was easier to make.
That is worth something. It is just not what I built the stack to be worth.