Founder Playbook · Sub Club by RevenueCat
9 tactics from Christian Selig
The Advantages of Working On an App You Care About
Watch the full episode“I ended up posting it in like the Apple subreddit I think and it really took off in a big way and people were really interested in beta testing it so kind of got to that point where I was like oh like this might have some legs.”
Post the beta in the community you are building for — that is your validation
Apollo's early traction came from a single post in a community Christian already lived in. The feedback was immediate, the beta filled fast, and the demand signal was real — not manufactured. Building for a community you already participate in shortens every loop: from idea validation to beta recruitment to launch distribution.
“The first day like it got a ton of downloads because there was a lot of pent up demand from people who saw the beta but was full and weren't able to get in so there were a lot of people who just jumped on the pro version immediately.”
Fill the beta, then open the gates — pent-up demand converts on launch day
Apollo was financially viable from day one of release — not because of marketing spend but because the waitlist had been building for a year. A restricted beta with visible scarcity trains users to act immediately when access opens. The best launch tactic is a beta too full to get into.
“I think I fell into every like developer trope where there was like feature creep there was working on like too many features instead of bugs... by some luck stroke of luck it came together and released.”
Every developer falls into feature creep — ship the buggy version, fix after
Apollo took a year and a half longer than it should have because Christian kept adding features instead of shipping. The same trap captures most solo developers. The fix is external pressure: a beta community demanding release, a public ship date, or just the discipline to declare the current build good enough and go.
“The feedback loop was so close by like it was like you know you were in the app you can just poke over here to kind of give some feedback and that made it really nice because there was no friction people always gave really good feedback.”
Build for a community you live in — the feedback loop needs zero friction
When your users already hang out in the same spaces you do, qualitative research happens passively. Apollo's subreddit made feedback instantaneous — no surveys, no user interviews, no recruitment. Building for a community you belong to means the product-market feedback loop is always on.
“The feedback people gave over the years really shaped it into something that I think became more than just like my ideal of what a Reddit client was it kind of got shaped into this what the perfect thing for a community would be.”
Community feedback shapes the product into something you could not design alone
Apollo started as Christian's personal vision of a Reddit client but became something broader through years of community input. The product that shipped was a collective artefact shaped by thousands of voices — which is exactly why it commanded such fierce loyalty. A solo founder with an active community can build better than a team without one.
“Your personal burn rate is probably like your number one can be your number one hindrance to risk-taking like as you increase your personal burn rate it just like lowers the opportunities that you can take.”
Personal burn rate is the biggest risk-taking constraint — keep it low while you build
The Apollo path worked in part because Christian burned through Apple intern savings while living cheaply with five other people. Lifestyle inflation is the silent killer of indie projects — every expense that raises your monthly floor raises the revenue threshold you need before you can afford to keep going. Lowering personal spend buys as much runway as raising revenue.
“It's that like hobby-slash-work barrier that's like get really dangerous where you're like oh like I'm working on this feature and it's a ton of fun and it's like 10pm... most great outcomes came through at least some period of like intense investment.”
Great products come from a period of obsessive intensity — that is not a warning
The work-life balance framing misses something about how great products get built. Apollo happened because Christian worked on it obsessively during a period when he had no commitments, no balance, just intensity. That phase is often necessary — not something to engineer away. The goal is to find the project that makes 10pm feel like fun.
“If you're building an app that you care about that you're passionate about that's you think is solving a problem or whatever whatever motivates you these businesses can be pretty sticky and durable.”
Caring about what you build is an unfair advantage clones can not copy
Apollo survived a decade and built one of the most devoted user bases in indie mobile history because Christian genuinely loved Reddit. That care showed in every detail: the gesture system, the comment threading, the design polish. A clone can copy features but can't replicate the judgment of someone who uses the product every day for years.
“Reddit was really big at the time... there wasn't really any like really iOS first app that really I loved so I was like you know screw it this is this could be a fun project.”
Scratch your own itch in a community you love — that is where great indie apps start
Apollo began not with a market research exercise but with a genuine gap Christian felt every time he opened Reddit on his iPhone. The best indie apps are built by people annoyed that the tool they want doesn't exist yet — because they will use the product obsessively, notice every flaw, and keep improving it long after a mercenary builder would have moved on.