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 a new mobile experience. I led a team of 15+ owning product and design strategy, technical specifications, App Store submission and client handoff. I was the bridge between CT's executive team and Fueled's engineers, design, QA, and growth experts across a multi-month, milestone-based build.

During this time we transformed as a team into an AI native organization across all phases of strategy, design, implementation, and stakeholder management. As PM I leveraged AI to accelerate this work and built 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 has decades of editorial weight, a mature web subscription business and a first-class content engine but lacked a mobile native experience. I was accountable for designing the strategy and delivering an experience that held the entirety of CTs current web offering 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 without any content migration, building a lean BFF middle layer and delivered via CT's existing back-end stack.

My Role

• Owned the v1.0 → v2 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 a PM Strategy & GTM Playbook with 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 demanded thoughtful UX strategy and technical design. CTs web-based editorial platform is based in Wordpress. 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 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 could optimize the experience without 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 we wrapped Coral's commenting API in custom Flutter front-end
• 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 Apple's App Store compliance due to 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 as anticipated. I proposed, that if argued correctly, CT would qualify as a Reader App (Guideline 3.1.3a), to send users to its own web checkout and 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

After direct negotations with Apple the app was approved without a significant 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