Christian apps were strong at Bible content but weak at fellowship, accountability, and ongoing relational support.
Case study
BelieverHub
A fellowship platform for the Christian community, designed around real relationships, prayer accountability, small groups, and church-led density instead of passive content consumption.
I shaped the differentiation, beachhead audience, IA, visual identity, design system, and phased handoff model.
The product is centered on groups, prayer, accountability, and church-led density rather than a generic faith content feed.
BelieverHub is live at believerhub.org with the fellowship core, groups, prayer, accountability partners, testimonies, worship, and an AI Bible assistant, shipped and public.
My contribution
- Defined the strategic wedge: YouVersion helps people read the Bible; BelieverHub helps people not walk alone.
- Built the information architecture around fellowship, prayer, groups, Bible support, worship, messages, profile, and admin moderation.
- Created the design token system, bilingual EN/FR structure, dark mode rules, and developer handoff documentation.
Challenge
Most Christian apps optimize for solo consumption: reading, listening, highlighting, and content discovery. But the underserved gap is relational accountability: knowing someone is praying for you, staying connected to a small group, and feeling less alone in faith.
The product also needed a beachhead that large incumbents could not copy easily: the Christian community, with language, culture, and church context shaping the experience.
Research insight
I mapped the faith-app landscape across two axes: solo to relational, and content to accountability. Incumbents clustered around digital, solo, content-first experiences. The open space was digital fellowship: groups, prayer, accountability, and visible support.
- Relationship, not content: the product needed to solve spiritual isolation, not compete as another Bible reader.
- Specific community: building for the Francophone and Creolophone Christian community created a defensible wedge.
- Local church alignment: the product strengthens church relationships instead of replacing them.
Strategy
Competitive mapping showed incumbents clustered around solo, content-first experiences. Digital fellowship and accountability was the open space.
The cold-start strategy is to seed one church at a time so small groups feel alive instead of scattered.
The MVP focuses on auth, groups, prayer, and feed before expanding into the full long-term vision.
Product architecture
Home, Community Feed, Prayer Center, Groups, and AI Bible Assistant create the relational center of the experience.
Bible Q&A, study plans, devotionals, memory verses, notes, prayer journal, and notifications support ongoing rhythm.
Churches, ministry, discipleship, messages, profile, search, and admin moderation make the product manageable beyond the MVP.
Key decisions
Prayer requests use "I'm praying" with a live counter and face-pile, making support visible and relational instead of transactional.
A fellowship product needs density. The go-to-market starts with real church communities instead of isolated global signups.
A responsive installable web app avoids app-store friction, supports church-led sharing, and stays lighter for slower mobile data.
Design system
- Defined a sacred but modern identity with navy, steel blue, grey, and a disciplined yellow accent.
- Created a signature verse moment: navy card, white editorial serif, italic verse treatment, and yellow accent rule.
- Used Fraunces for headings and verses with Inter for UI, making the product feel devotional without losing usability.
- Designed dark mode, WCAG AA targets, visible focus rings, reduced-motion support, and contrast rules from the start.
Constraints as UX
Bible text must come from licensed APIs with attribution instead of hardcoded translations.
The assistant should cite real verses, show disclaimers, defer to pastors, and never invent doctrine.
Private prayers, journals, DMs, and music rights required data-layer privacy and external audio links instead of hosted content.
Developer handoff
The handoff was structured so implementation could inherit the design logic instead of recreating decisions from screenshots.
- Design tokens for color, type scale, spacing, radii, light mode, and dark mode.
- A complete navigable HTML model of the product surfaces as the visual source of truth.
- A persistent knowledge file covering product vision, roles, rules, design tokens, and implementation constraints.
- A phased prompt sequence: frontend first, backend later, Row-Level Security from day one.
Selected product direction
Outcome
BelieverHub went from 0-to-1 design and strategy through active development handoff to a live, public product at believerhub.org.
- Defined a defensible product position around fellowship rather than content consumption — now stated on the live site itself as "Not another app. A family."
- Created a complete IA with 17 screens and a phased MVP that shipped lean: fellowship groups, prayer with live participation counts, accountability partners, testimonies, worship, and an AI Bible assistant.
- Turned licensing, AI accuracy, music rights, privacy, and security into design inputs instead of late-stage risks.