Global Media App

I was engaged by Fueled (NY/London) to build Christianity Today's first-ever mobile app: a cross-platform Flutter build (iOS + Android) bringing 70+ years of journalism and a global audience to mobile. I guided a global team of 15+ owning product and design strategy, technical specifications, App Store submission and client handoff. I was the connective tissue between CT's executive team and Fueled's engineers, design, QA, and growth experts across a multi-month, milestone-based build.

We transformed as a team over these 6 month into an AI native organization across all phases of strategy, design, implementation, and stakeholder communication. As PM I leveraged AI to build features with in-depth technical guidance and executable code.

Click to Download CT Mobile App

Stack: Flutter (Dart, CLEAN architecture, BLoC) · FastAPI · PostgreSQL · Redis · WordPress VIP · Piano · Algolia · Coral · Megaphone · Firebase · Google Ad Manager · Cursor · Claude Code · Linear · Notion · Figma · Sentry

The Brief

CT had decades of editorial weight, a mature web subscription business and a consistent content engine but no first-class mobile experience. I was accountable for creating and delivering a first class mobile experience that held the entirety of CTs offerings including articles, magazines, podcasts, videos, a daily briefing, and member-gated content, all plugged into their existing identity, paywall, search, and CMS infrastructure. We were able to pull this off with zero content migration. Everything resolves live through CT's existing stack.

My Role

• Owned the v1.0 → v1.1 roadmap and feature scope end to end
• Wrote every product spec & acceptance criteria, proposed BFF endpoint contracts, analytics taxonomies, compliance docs
• Managed the full Linear backlog and acted as technical translator between the client and engineering
• Built the PM Strategy & GTM Playbook — vision, north star, launch sequencing, analytics activation
• Owned App Store and Play Store submissions, including compliance negotiation with Apple

‍

The Build

I was tasked with taking a complex content-rich web experience and producing a personalized high-value mobile experience for users. This required thoughtful UX strategy and thorough technical design. CTs web-based editorial platform is housed in Wordpress and we had to decide how to provide over 70+ years of content stored in wordrpress for a mobile experience that felt native. Rather than have the Flutter app talk directly to WordPress and a half-dozen third-party services, we built a FastAPI BFF that sits in the middle as the complexity sink. The app talks to one clean API; the BFF fetches from the upstreams, normalizes messy payloads, enforces entitlements, and caches. Paywall, search, images, comments, deep linking all resolved server-side, to keep the client thin so we optimize the experience without constantly shipping a new build.

The rest of the system, briefly:

• Content: the BFF wraps WordPress VIP, with a custom WordPress-to-Flutter rendering engine supporting 15+ block types so decades of editorial render natively instead of as a webview
• Identity & paywall: Piano ID via OAuth 2.0 + PKCE (no client secret ever stored on-device), tiered content gating, SSO hand-off to web, GDPR-compliant account deletion
• Search: Algolia, shaped through the  into the Explore tab
• Media: persistent podcast player with background audio, lock-screen controls, and offline playback; Megaphone for podcasts, VideoPress for video, PDF magazine archive
• Commenting & reactions: a client-signed change order that became the BFF's first PostgreSQL layer, and a differentiator no app in CT's peer set ships natively
• Analytics: a Piano Analytics taxonomy of 45+ properties, with Share Rate per Article Open as the north star

The app itself is four tabs, each with a distinct job: Today provides the daily habit — briefing, devotional, continue-reading), Media (podcasts and video), Explore (search and discovery), and My CT (account, bookmarks, preferences).

Dancing With Apple

One issue we faced was in App Store compliance and the nature of revenue generation for the app. Our subscribe flow originally loaded CT's web checkout in an in-app webview. My compliance audit flagged this as a critical blocker under Guideline 3.1.1 and Apple rejected the app for exactly that reason 26 days later. I proposed, that if argued correctly, CT would qualify as a Reader App (Guideline 3.1.3a), so it can send users to its own web checkout and could bypass the hefty subscription tax Apple places on apps. The reasoning I documented for the client:

• Revenue — IAP surrenders 15–30% of every subscription dollar, forever. The external-link path keeps revenue in CT's existing Piano infrastructure
• Scope — External link = five well-scoped Flutter tasks. IAP = a full StoreKit 2 build and two parallel subscription systems to maintain forever
• Timeline — days-to-weeks to resubmit vs. months
• Clarity — I tracked the Epic v. Apple rulings and was upfront that the current zero-commission window is favorable but not permanent

The app was approved by Apple without a rebuild and cleared by Google on the first submission cycle.

Outcomes

• Cross-platform iOS + Android from a single Flutter codebase
• Zero content migration and full integration with CT's existing stack
• BFF load tested to 1,000 concurrent users at p95 < 500ms
• App Store approval via the Reader App path
• Expanded scope: client-signed change order for native commenting & reactions
• Production deployment with Sentry monitoring, then structured documentation and repo handoff to the client team