§ Case study · Portfolio
Lirix — social reading tracker
A respectful app: no ads, no tracking, no endless feed.
MAG&Cie · No. 2026 · 8 weeks · Solo · Android + Web + iOS
/ In short
A respectful social reading tracker, designed and shipped solo by MAG&Cie in about eight weeks: personal library, streaks, closed friends feed, gamification quests. A single TypeScript codebase for iOS, Android and Web. No advertising, no tracking — the product pays for itself through Premium, never through its readers' data.
Context
A simple need, a clear ambition
Track what you read without handing your data to a book giant — and without drowning in an algorithmic infinite feed.
The reading tracker market is saturated at both extremes. On one side, ambitious social networks that monetise attention through advertising and biased recommendation. On the other, minimalist reading journals that offer no social layer at all. Lirix targets the missing middle: useful sociability, without an attention debt.
MAG&Cie launched the project in-house as a proving ground — demonstrating in practice that we can ship end-to-end a complete cross-platform product: native mobile, static web, backend, workers, CI/CD, store distribution and GDPR compliance. Eight weeks of intensive development between the initial scoping and the first store submission, with no dilution of the technical scope.
Product decisions
Four structural trade-offs
Every choice was made to keep the promise: a sober, respectful tool — social without being toxic.
Quests instead of an infinite feed
Doomscrolling is absent by construction. Instead, a claim-based quest system rewards consistency and discovery — finite objectives, weekly comebacks, never a stack of cards piled up to infinity.
Zero ads, zero tracking
Free Solo + Premium (monthly or lifetime) business model. No ad SDKs, no third-party analytics trackers, no data resale. Profitability comes from perceived value, not captured attention.
Friends feed, not strangers
The social graph is deliberately closed: only people added explicitly. Phone numbers are SHA-256 hashed client-side for contact matching — never stored in plain text server-side.
Streaks that help, never shame
Consistency is flagged but never wielded as punishment. No punitive notifications, no public failure — a discreet counter the reader checks if they feel like it.
Technical stack
Technical stack
Every layer picked to keep the promise: one person, three platforms, production from day one.
- Mobile
- Expo SDK 54, React Native 0.81, Hermes, Fabric (New Architecture), Expo Router 6
- Web
- Same Expo codebase → static SPA export, Vercel deploy
- Styling
- NativeWind (Tailwind on React Native), declarative dark mode
- Client state
- Zustand + TanStack Query + AsyncStorage persister
- Backend
- Fastify, Prisma, Zod, RFC 9457 problem+json, Fly cdg region
- Database
- Supabase Postgres (transaction pooler 6543)
- Cron workers
- BullMQ + Redis, node-cron: release scan, weekly digest, monthly recos, streak-at-risk, reading-duels tally
- Auth
- Supabase JWT + JWKS + HS256 fallback, PKCE OAuth
- CI/CD
- GitHub Actions: lint + typecheck + tests + i18n parity + DB migration + prod deploy
- Distribution
- EAS Build cloud, App Store Connect API auto-submit, Google Play internal track
- Observability
- Fly logs, Supabase logs, GitHub Actions run history
Delivery
The method — how to ship a cross-platform app in 8 weeks
Four back-to-back phases, one operator, an architecture designed to keep the promise.
- M01
Product scoping
Clear positioning (no infinite feed, no ads, no tracking), Free Solo + Premium business model, Gamification 2.0 (XP, quests, duels), sprint-driven Notion roadmap.
- M02
Architecture and build
Single TypeScript monorepo for mobile (Expo/RN New Arch), web (SPA from the same codebase), backend Fastify + Prisma + Supabase, BullMQ + Redis cron workers. NativeWind design system, Zustand + TanStack Query state.
- M03
Security and GDPR
GDPR by design: instant soft-delete + automatic purge after 30 days, SHA-256 hashed phone numbers for contact matching, OAuth PKCE + JWT verified via JWKS, strict CSP, secrets only in GitHub secrets and Fly secrets.
- M04
Distribution and CI/CD
EAS Build cloud + App Store Connect API auto-submit + Google Play internal track. End-to-end GitHub Actions (lint, typecheck, tests, DB migration, API + workers + web deploy + mobile OTA via EAS Update). Observability via Fly logs, Supabase logs, Actions history.
Results
Key numbers
What was shipped in eight weeks — real numbers on the technical perimeter, not user vanity metrics.
1
person — design, code, security, distribution
~8
weeks of intense dev from idea to stores
~40,000
lines of TypeScript across the monorepo
3
simultaneous platforms (iOS, Android, Web) — a single codebase
23
gamification quests + XP, levels, badges and duels
6
OAuth providers (Apple, Google, Microsoft/Entra, email…)
Version 1 in production, continuous iteration. Usage metrics remain modest and honest — the product is young; the demonstration is about delivery capability.
What this proves
An end-to-end demonstration
If MAG&Cie ships this on internal time, imagine what a firm of the same shape ships on a scoped engagement with a real budget.
« A respectful app is not proven by a marketing page; it is proven by what was deliberately left out. »
— Product note · MAG&Cie
- 01
Ship solo what a 4-person team would take 6 months to build
- 02
Own the whole chain: product, tech, security, deployment, store distribution
- 03
Understand App Store and Google Play stakes (5 rejections overcome)
- 04
Automate end-to-end (CI/CD, OTA, DB migrations, auto-submit)
- 05
Design for security and GDPR upfront (hashing, proper JWT, CSP, automated purge)
- 06
Wire a SaaS service, a mobile app and a Prisma backend into production the next day
/ FAQ
Frequently asked questions
What we get asked most about Lirix — and what we can say about it.
How long did it take to ship Lirix?
About 8 weeks of intense development, from idea to stores. One person: product design, code, security, deployment, distribution — a fractional CTO wearing the Product Owner and RSSI hats at the same time.
What technical stack was used?
Single TypeScript monorepo. Mobile: Expo SDK 54 + React Native 0.81 New Architecture. Web: same Expo codebase exported as a static SPA and deployed on Vercel. Backend: Fastify + Prisma + Zod, Fly cdg region. Database: Supabase Postgres (transaction pooler 6543). Workers: BullMQ + Redis. CI/CD: GitHub Actions. Distribution: EAS Build cloud.
How was security and GDPR handled?
GDPR by design from the very first commit. Instant user-side soft-delete + automatic purge worker after 30 days (executable right to be forgotten). Phone numbers hashed with SHA-256 client-side — never stored in plain text. OAuth PKCE + JWT verified via JWKS with signed HS256 fallback. Strict CSP, HSTS, secrets only in GitHub secrets and Fly secrets.
How many platforms is Lirix available on?
Three simultaneous platforms — iOS, Android, Web — from a single TypeScript codebase. iOS via the App Store, Android via Google Play, Web at lirix.club. Automated distribution: every push updates the API, workers, web and pushes a mobile OTA via EAS Update.
What does Lirix show a future MAG&Cie client?
That MAG&Cie can ship solo a complete product — mobile + web + backend + infra + security — without spinning up a team. That the firm owns the entire chain: product, tech, security, deployment, store distribution (5 App Store rejections overcome). Automation and GDPR designed for upfront.
Can we get similar support from MAG&Cie?
Yes. Every engagement is scoped bespoke. Whether it's a fractional CTO, an end-to-end product + tech + security engagement or a feasibility audit, the starting point is a conversation about scope and ambition. Contact us via /contact or book a call directly.