Marcel Hoppe

Update on the PostHog feature flag quirk from my 2025 recap: the fix landed, and it's working great! Events drop to 0 exactly on Jan 6 (release day) — trial started events now counting correctly in experiments. Huge thanks to @marandaneto and the @posthog team for the fast response. Dev tools that listen and ship fixes quickly are the best.❤️ #PostHog #MobileDev #IndieDev

@jacobrodri_ Indeed sounds like a dream life... until the kids have to attend school🥲

after a few weeks in vietnam, i’m convinced the best tax strategy for a european founder is: - tax residency in paraguay/panama (0% tax and no need to live there) - spending the winter in vietnam/thailand/philippines (amazing weather, beaches, food) - rest of the year (6 months) in your home country, without paying the 50% european tax sounds like a dream life

@Bhavani_00007 Big fan of Claude Code. Started trying Codex today 👍🏼

be honest, which AI tool is best for coding?

Zero chill, maximum respect 🫡

@jakemor Can’t wait 🤩

Next version of Superwall is going to blow your mind

Regarding the feature flag issue I mentioned in my recap: We’re A/B testing different UI flows for trial started/cancelled events. When reviewing early results, I noticed inconsistencies: the experiment showed 3 trial cancelled events but 0 trial started events linked to it. (see experiment results screenshot) Digging into those 3 users, they all had nearly identical timelines: 1. `Identify` (with `$ initial_app_build` already set) 2. `Feature flag called` → false ("No matching condition set") 3. `rc:trial_started_event` (sent, but not counted in the experiment) 4. `Feature flag called` → coins/control ("Matched condition set 1") 5. `rc:trial_cancelled_event` (sent and correctly counted) The flag's release condition is: Set 1 – `$ initial_app_build` greater than 1044 (rolled out to 100% of users matching this, no overrides). I expected the `rc:trial_started_event` to be attributed to the experiment too. From what I see, this only happens if the first flag call (Step 2 above) already returns the variant. In these cases, the initial call returns false, and only later calls resolve to the correct variant. (see events timeline screenshot) This is probably a timing issue of when things are evaluated. I could come up with some custom logic to overcome this, but I would say it is a common use-case to target specific app versions when experimenting on mobile. And the $ initial_app_build provided by the SDK is the perfect property for that. Either way, super happy with PostHog overall❤️— just sharing in case it helps others (or sparks an improvement). Really appreciate the quick response! 🙌

Thanks again for reaching out! One thing I stumbled on: Changing the property definition type to numeric in PostHog made >/< comparisons work even though $ app_build was ingested as a string (with type mismatch warnings). To make it fully reliable, I ended up adding client-side conversion. I attached the `setBeforeSend` block I now use to auto-convert build numbers. (Code in another reply) Not sure if this is covered clearly in the docs — would a more prominent note (or even an optional config flag in the mobile SDKs for auto-converting common properties like build number) be helpful for others? I feel Integer build numbers are pretty common these days in mobile apps. Happy to chat more if useful!

As 2025 comes to a close, tons of revenue recaps are dropping. And rightfully so — money keeps the lights on and lets us keep building. But for me this year, the real highlights aren't the numbers. It's the lessons learned along the way — the ones that stick forever and compound into everything I build next. Here's my raw takeaways from another year of grinding and growing.🧵

```swift let config = PostHogConfig(apiKey: MainConstants.postHogApiKey, host: MainConstants.postHogHost) config.setBeforeSend({ event in // Convert build number strings to integers func convertBuild(_ key: String) { if let value = event.properties[key] as? String, let int = Int(value) { event.properties[key] = int } } // Note: PostHog SDK auto-populates $set and $set_once from root properties convertBuild("$app_build") convertBuild("build") convertBuild("previous_build") return event }) ```

I'd love to have this in Superwall. We keep falling back to PostHog (with all Superwall events) to analyze campaign performance. An overall campaign "Results" view would also be amazing, so I don't need to check in each audience individually. Another (probably too specific and too much to ask) scenario where we use our external analytics tool is when we run user seed bucket experiments across multiple campaigns—users with seeds 0-19 in bucket A, 20-39 in B, etc.—and each bucket experiences different paywalls, holdouts, etc., within each campaign.

Update: I made myself this dashboard since admittedly @superwall isn't great for analyzing trials. Do you find this useful? Should we add it to Superwall? Any ideas? It shows trials broken down by product, and how many are pending, cancelled, billing issues etc. Its a live view for "how much do you stand to make today?". You can also peak into tomorrow, the next day etc. to see how many people are pending / cancelled for any given product. All this is to answer the question you have everyday if you're burning money on ads... "Did I make money today?" Sidenote: been absolutely loving lovable for internal dashboards.

14/ In 2026, I'm doubling down on that: more experimentation, deeper dives, and sharing the wins/fails along the way. Learning compounds forever. What about you? What's your top 2025 lesson — and what are you excited to learn/build next year? Drop it below. Here's to 2026 🚀

13/ Through-line of 2025? Learning is iterative and experimental. From iOS templates to backend patterns to pixel-perfect landing pages — it's about turning ideas into shipped reality faster, guided by better vibes.