From Pirated Content to a Protected Platform — Built and Shipped in 8 Months
Led the end-to-end development of a multi-platform LMS ecosystem for Pakistan's best-selling novelist Nemrah Ahmad — React Native app, Next.js admin panel, and marketing website — with screen-capture prevention, audio-synced reading, and dual App Store / Play Store launch.
Project Context
The Problem
Nemrah Ahmad's novels and courses were being pirated — third parties were copying her content, selling it cheaply, and leaving her with no revenue or control. She needed a proprietary platform to reclaim ownership.
Constraints
- —Feb–Sep 2024 deadline (8 months)
- —Cross-platform mobile (iOS + Android)
- —No existing codebase to build on
- —Multi-platform: app + admin + website
- —Content must be piracy-resistant
- —Urdu & English language support
- —Junior developer to manage
My Role
Lead Developer — I made every technology decision, set up the project architecture, managed a junior developer, collaborated with backend and design teams, and personally built the majority of the product. I was the sole person accountable for the engineering side.
01 — Problem
A Best-Selling Author Losing Revenue to Piracy
Nemrah Ahmad is one of Pakistan's most widely read novelists — her work commands a large, loyal audience. But that popularity came with a painful side effect: pirated copies of her novels and courses were circulating freely online. Third parties were reproducing her content, packaging it cheaply, and profiting without her knowledge. She had no technical means to stop it.
The situation demanded a purpose-built platform — one she owned, controlled, and that could enforce content protection at the OS level. A generic SaaS tool or off-the-shelf LMS would not cut it. The solution had to be mobile-first (her audience lives on their phones), cover novels and courses, support community features, and actively prevent screenshots and screen recording. The stakes were real: this was her livelihood.
02 — Situation
Three Platforms, One Team, Eight Months
Before a single line of code was written, I was in the room for the pre-development discussions with the backend developer, the manager, and the designer. My role wasn't just to execute — it was to shape what we were building. The scope that emerged was significant: a React Native mobile app, a Next.js admin dashboard, and a Next.js marketing/content website, all integrated, all launched within eight months.
I had a junior developer alongside me, but the architecture decisions, technology choices, and the majority of implementation fell to me. We were working with a backend developer building the API, a designer providing Figma files, and a manager coordinating the overall project. My job was to translate all of that into functioning product and ensure the engineering side didn't become the bottleneck.
iOS + Android — novels, courses, audiobooks, community, offline reading, screen guard
Multi-role ACL, content upload, Lexical editor, audio-text sync, subscription management
Marketing, content listing, public content playback, deep linking to app
03 — Thinking
The Decisions That Defined the Platform
React Native CLI over Expo — deliberate loss of convenience for control
Expo would have been faster to start and easier to hand off. I chose React Native CLI instead. The core reason was control: react-native-screenguard (screen-capture prevention) is a native module that requires direct access to the Android/iOS layer. Expo's managed workflow makes this either impossible or unreliable. Screen guard was non-negotiable for this client, so the build tooling had to support it without compromise. The tradeoff — slower CI, more complex build scripts — was worth it.
RNEUI for UI — speed without sacrificing theming
With a large UI surface (reader, audiobook player, community, dashboard, tasbeeh, library) and one lead developer, I needed a component framework that handled theming and common patterns without boxing me in. React Native Elements (RNEUI) gave us a consistent design system and dark/light theming out of the box. This let the junior developer build UI screens faster while I handled the complex logic layers.
Lexical for the admin content editor — custom extension for audio sync
The audiobook transcript sync feature required a rich text editor where each text segment could be annotated with a timestamp — 'highlight this sentence when the audio is between 00:12 and 00:18.' No out-of-the-box editor supports this. I chose Lexical (Meta's extensible editor framework) and built a custom node type that stores time intervals per text block. This powers the synchronized transcript view in the mobile app reader.
Redux + redux-persist for state — justified by complexity
Some projects are over-engineered with Redux. Here it was justified: user authentication state, library state, download queue, reader preferences, community state, and tasbeeh counter all needed to survive app restarts and be accessible across deeply nested screens. redux-persist with MMKV as the storage engine gave us fast, reliable persistence without the complexity of a custom solution.
Screen capture prevention as a first-class architectural requirement
Most apps treat security as an afterthought. Here, content protection was the entire reason the platform was being built. react-native-screenguard was integrated from day one on both Android (FLAG_SECURE on the Activity window) and iOS (UITextField overlay trick). Every screen displaying paid content has this active. It was tested across real devices on both platforms before any other feature was considered complete.
Deep linking with custom domain — bridging web to app seamlessly
The marketing website lists all novels and courses. When a user taps a novel on the website and the app is installed, they should land directly inside the app on that novel's screen. I implemented universal links (iOS) and app links (Android) using a custom domain, with React Navigation handling the in-app routing. This closed the conversion loop from website discovery to in-app engagement.
04 — Action
What I Built
I set up the full project architecture across all three platforms from a blank repository, made all technology decisions, managed the junior developer's workload, and personally implemented every complex feature. Here is what shipped.
React Native Mobile App
Next.js Admin Panel
Next.js Marketing Website
Delivery Timeline
Feb 2024
Discovery & Architecture
Pre-development meetings with backend, designer, and manager. Technology decisions locked. Project setup across all three repositories. Architecture and navigation structure defined.
Mar–Apr 2024
Core Mobile App
Authentication, dashboard, library, and reader screen. Screen-capture prevention integrated and verified on real devices. Offline chapter download with file system management.
May–Jun 2024
Audiobooks + Community + Admin V1
Audio player with synced transcript using custom Lexical nodes. Community feed (gifted-chat), discussion boards, status feature. Admin panel V1: content upload, user management, ACL.
Jul 2024
Payments + Notifications + Deep Links
Stripe + in-app purchase integration. Manual payment approval flow. Firebase push notifications with custom event sender. Deep linking via custom domain (universal links / app links).
Aug 2024
Website + Admin Polish + QA
Next.js marketing website built and integrated. Admin panel ACL refinement, subscription management, tasbeeh management. Full QA across Android and iOS real devices.
Sep 2024
App Store & Play Store Launch
Set up Google Play Console and App Store Connect. Built release artifacts, wrote store listings, passed both review processes. App went live on both platforms.
Stack
Technology Choices
React Native CLI
Cross-platform iOS + Android, no Expo constraints
TypeScript
Strict typing across all three projects
Redux Toolkit + redux-persist
Complex cross-screen state with MMKV persistence
Firebase Messaging
Push notifications and custom event payloads
Stripe + react-native-iap
Subscription billing and in-app purchases
Next.js (Admin + Website)
Admin dashboard and marketing website — both App Router
Lexical Editor (custom)
Extended with audio-timestamp nodes for transcript sync
MUI + CASL
Admin UI and multi-role access control
App Screenshots
The Finished Product
11 screens from the shipped app — click any to enlarge. Use arrows or dots to browse.
1 / 3 — Splash Screen · Click any screen to enlarge
05 — Results
Shipped, Live, and Protecting Her Content
- ✓Nemrah Ahmad now controls her content distribution end-to-end — no third-party platform dependency
- ✓Piracy vector closed: screen-capture prevention prevents content from being copied via screenshot or recording
- ✓Community engagement: fans can message Nemrah Ahmad directly and receive replies visible to all — a unique community mechanic
- ✓Offline reading with per-chapter downloads gives users access without connectivity — important for the audience demographic
- ✓The audio-synced transcript is a genuinely differentiated feature: text highlights word-by-word as the audio plays
- ✓Manual payment approval flow means the admin team can onboard users who pay via bank transfer — serving users without cards
- ✓Deep linking closes the web-to-app conversion loop: website discovery translates directly to app engagement
06 — Reflection
What This Project Proved
This was the most scope I had ever owned end-to-end. Three platforms, eight months, one lead developer. The moments that tested me most weren't the complex features — they were the decisions made under ambiguity before development started. Choosing React Native CLI over Expo, deciding to extend Lexical rather than build a custom editor, structuring the Redux store to survive across all three apps — these choices made or broke the timeline.
Managing the junior developer was a skill I had to develop alongside the code. Delegating UI screens while retaining oversight on logic integration meant I had to stay aware of two levels of complexity simultaneously. In hindsight, I would invest more time in a shared technical onboarding doc so the junior could be unblocked without always needing me.
The screen-capture prevention feature is the one I'm most proud of — not because it was technically the hardest, but because it was the most important to the client and the one most developers would have treated as an edge case. I treated it as a first-class requirement from day one.
What I'd do differently
- →Earlier automated testing for the reader and audio-sync logic — bugs there were expensive to trace
- →A shared component library between admin and website from the start — some UI was duplicated
- →More granular feature flags for the admin panel so new content types could be rolled out without a full redeploy
"The most valuable thing I built wasn't a feature — it was the system that made a novelist's work impossible to steal."
— Muhammad Hassan, personal reflection