Forem: Muhammad Zulqarnain

Stop Building AI Wrappers. Start Building AI Products.

Muhammad Zulqarnain — Fri, 24 Apr 2026 06:00:00 +0000

Everyone and their brother is building an AI wrapper right now.

You know the type: "I built a ChatGPT UI with a prompt." "I wrapped Claude and added a database." "I made an AI that does X by just calling the API."

These are not products. They're proofs of concept that will be dead in 6 months.

Here's the difference between an AI wrapper and an AI product, and why it matters.

What's an AI Wrapper?

Wrapper = LLM API + UI/UX

"Prompt builder for GPT" — still just calling GPT
"AI email writer" — just Claude, but for emails
"Chat interface that remembers context" — ChatGPT but persistent

These have zero defensibility. When OpenAI releases ChatGPT Plus with the same features, your wrapper dies.

What's an AI Product?

AI Product = (Proprietary Data + Specialized Model + Workflow Integration + User Loop)

Cursor: Code editor that understands your specific codebase. Remove AI, product breaks.
Perplexity: Web search + AI reasoning over sources + citations. The synthesis is the product.
Replit Agent: AI that executes code, sees errors, iterates. The feedback loop is the product.

The 5 Differences

1. Proprietary Data

Wrapper: Uses public information
Product: Has a data moat

2. Specialized vs. General

Wrapper: Uses a general LLM
Product: Fine-tunes for specific task

3. Workflow Integration

Wrapper: Standalone tool
Product: Integrated into how users work

4. Feedback Loop

Wrapper: Fire and forget
Product: Learns from user behavior

5. Defensibility

Wrapper: Dead when the LLM vendor ships the same feature
Product: Moat that gets wider with users

How to Build an AI Product

Start with a specific, narrow problem
Identify your data advantage — if the answer is "none," you're building a wrapper
Build the feedback loop from day 1 — capture accept/reject/edit signals
Integrate into user workflow
Fine-tune or specialize your model
Think about the data flywheel

The Investment Thesis

Wrapper: "We built a UI for Claude." — VCs pass
Product: "We trained a model on your domain data and it handles 60% of your support tickets." — VCs listen

Build for defensibility. Not demo impressiveness.

More at zunain.com.

From $200/Month to Free: Running OpenClaw with Local AI Models

Muhammad Zulqarnain — Sun, 19 Apr 2026 18:15:45 +0000

This is a submission for the OpenClaw Writing Challenge

The Problem: AI Assistant Costs Are Skyrocketing

If you're running OpenClaw with cloud-hosted LLMs like Claude or GPT-4, you know the pain. Premium API access can easily cost $200/month or more, and that's assuming moderate usage. For developers, founders, or anyone automating workflows extensively, those costs compound fast.

But here's the thing: OpenClaw doesn't require cloud AI. You can run it entirely locally with open-source models—and in many cases, get comparable results for $0/month in API fees.

This guide walks through three deployment tiers, from completely free to budget-friendly, showing you how to cut your OpenClaw costs to zero while maintaining functionality.

Understanding Your Options

Tier 1: Completely Free (Ollama + Local Models)

Cost: $0/month

Hardware: Any spare laptop/desktop with 8GB+ RAM

Best For: Personal automation, learning, experimentation

How it works:

Ollama lets you run powerful open-source models like Qwen 2.5 (7B/14B), Llama 3, or Mistral locally. These models are surprisingly capable for most automation tasks—code generation, data extraction, text summarization, and workflow orchestration.

OpenClaw connects to Ollama as a model provider, treating your local instance like any cloud API.

Setup Steps:

Install Ollama (Mac/Linux/Windows):

   curl -fsSL https://ollama.com/install.sh | sh

Pull a capable model:

   ollama pull qwen2.5:14b
   # or for lower-end hardware:
   ollama pull qwen2.5:7b

Configure OpenClaw:

In your OpenClaw settings, switch the model provider to ollama and point it to http://localhost:11434.
Test your setup:

Create a simple skill (e.g., "Summarize my emails") and verify it works with your local model.

Tradeoffs:

Your device needs to stay on 24/7 for skills to run
Slightly slower inference than cloud APIs
Smaller context windows (typically 8K-32K tokens vs 128K+ for cloud models)

Real savings: If you were paying $200/month for Claude API access, that's $2,400/year saved.

Tier 2: Budget Cloud ($10-30/month)

Cost: $10-30/month

Hardware: None (cloud-hosted)

Best For: Production workflows, team usage, 24/7 availability

How it works:

If running a local device 24/7 isn't practical, you can deploy Ollama on a cheap VPS (Virtual Private Server) and point OpenClaw to it remotely.

Alternatively, use budget-friendly cloud APIs like:

Minimax API: ~$0.001 per 1K tokens (~$20-30/month for heavy use)
Groq: Fast inference, generous free tier
Together AI: Competitive pricing on open models

VPS Setup Example (DigitalOcean/Hetzner):

Spin up a VPS (~$10-15/month for 8GB RAM):

   # SSH into your VPS
   ssh user@your-vps-ip

Install Ollama:

   curl -fsSL https://ollama.com/install.sh | sh
   ollama pull qwen2.5:14b

Expose Ollama (use a reverse proxy like ngrok or Tailscale for secure access):

   ollama serve --host 0.0.0.0

Point OpenClaw to http://your-vps-ip:11434

Tradeoffs:

Small monthly cost but still 10x cheaper than Claude Max
Requires basic VPS management skills
Latency depends on VPS location

Real savings: Instead of $200/month on cloud APIs, you're paying $15-30/month—saving $170-185/month or $2,040-2,220/year.

Tier 3: Hybrid Approach (Best of Both Worlds)

Cost: Variable ($0-50/month depending on usage)

Strategy: Use local models for routine tasks, cloud APIs for complex reasoning

How it works:

OpenClaw supports multiple model providers simultaneously. You can configure different skills to use different models:

Routine automation (email filtering, data extraction) → Ollama (free)
Complex reasoning (code review, strategic planning) → Claude/GPT-4 (pay-per-use)

This hybrid approach optimizes for both cost and capability.

Configuration Example:

skills:
  email_summarizer:
    model: ollama/qwen2.5:14b

  code_reviewer:
    model: anthropic/claude-3-opus

Real savings: If 80% of your tasks run locally and 20% use cloud APIs, you're looking at ~$40/month instead of $200—saving $160/month or $1,920/year.

Choosing the Right Model

Not all models are created equal. Here's what works well for OpenClaw:

Model	Size	Best For	Context Window
Qwen 2.5	7B-14B	General automation, coding	32K tokens
Llama 3.1	8B-70B	Reasoning, chat	128K tokens
Mistral	7B-22B	Fast inference, multilingual	32K tokens
DeepSeek Coder	6.7B	Code generation, debugging	16K tokens

For most users, Qwen 2.5 14B offers the best balance of capability and resource requirements.

Real-World Example: My 5-Agent Setup

I run 5 OpenClaw agents entirely on Ollama using a spare MacBook Air (16GB RAM):

Email Assistant: Filters, summarizes, drafts replies
Code Helper: Generates boilerplate, reviews PRs
Research Agent: Monitors RSS feeds, summarizes articles
Data Extractor: Pulls structured data from websites
Task Scheduler: Manages my Notion workspace

Total monthly cost: $0 (minus electricity, ~$2-3/month)

Previous cloud API cost: ~$180/month

Annual savings: $2,160

The MacBook runs 24/7, but I was going to keep it plugged in anyway. The agents paid for themselves in week one.

Getting Started: Your First Local OpenClaw Agent

Here's a step-by-step walkthrough to create your first cost-free OpenClaw skill:

1. Install Prerequisites

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model
ollama pull qwen2.5:14b

# Verify it's running
ollama list

2. Configure OpenClaw

In your OpenClaw instance:

Navigate to Settings → Model Providers
Add a new provider: Ollama
Set endpoint: http://localhost:11434
Test connection

3. Create a Simple Skill

Let's build an Email Summarizer:

# Example skill configuration
name: "Daily Email Summary"
trigger: "cron: 0 8 * * *"  # Run at 8 AM daily
model: "ollama/qwen2.5:14b"

prompt: |
  Summarize these emails into a concise bullet-point list.
  Focus on action items and key information.

  {email_content}

output_format: "markdown"
notification: "slack"

4. Test & Iterate

Run the skill manually first:

openclaw run email-summarizer --test

Once it works, let it run on schedule. Monitor performance and adjust the prompt as needed.

Tips for Optimizing Local Model Performance

Use quantized models: GGUF 4-bit quantization runs 2-3x faster with minimal quality loss
Batch requests: Process multiple items together to maximize throughput
Cache responses: For repetitive tasks, cache and reuse model outputs
Monitor resources: Use htop or Activity Monitor to track CPU/GPU usage
Upgrade RAM if needed: 16GB is the sweet spot for running 14B models comfortably

When Cloud APIs Still Make Sense

Local models aren't always the answer. Stick with cloud APIs when:

You need cutting-edge reasoning (GPT-4o, Claude Opus for complex tasks)
Context windows matter (analyzing 100K+ token documents)
Latency is critical (sub-second response times)
You don't have suitable hardware (less than 8GB RAM)

The hybrid approach (local for most tasks, cloud for special cases) often delivers the best ROI.

Conclusion: Take Control of Your AI Costs

OpenClaw's flexibility means you're not locked into expensive cloud APIs. Whether you go fully local with Ollama, deploy a budget VPS, or use a hybrid strategy, you can dramatically reduce costs without sacrificing functionality.

Key takeaways:

✅ Local models (Ollama + Qwen/Llama) work for 80%+ of automation tasks
✅ VPS deployment costs $10-30/month vs $200+ for cloud APIs
✅ Hybrid approach balances cost and capability
✅ Annual savings of $1,920-2,400 are realistic

If you're spending over $100/month on AI API access, it's time to evaluate local options. OpenClaw makes it easy.

Resources

OpenClaw Docs: docs.openclaw.ai
Ollama: ollama.com
Qwen 2.5: huggingface.co/Qwen
Budget VPS Providers: DigitalOcean, Hetzner, Vultr

Have you switched to local models for OpenClaw? What's your setup? Drop a comment below!

EcoMind: AI Carbon Footprint Analyzer for Earth Day 2026

Muhammad Zulqarnain — Sun, 19 Apr 2026 16:05:04 +0000

What I Built

EcoMind is an AI-powered carbon footprint analyzer that helps individuals understand their environmental impact and receive personalized, actionable recommendations to reduce their carbon emissions.

Live Demo: https://ecomind-coral.vercel.app
GitHub: https://github.com/mzunain/ecomind

Demo

EcoMind provides:

🌍 Instant carbon footprint analysis based on your lifestyle
📊 Sustainability score (1-10) with detailed breakdown
💡 Top 5 personalized reduction actions ranked by impact
🌱 Region-specific advice (optimized for Nordic countries)
⚡ Fast, beautiful dark theme UI

Journey

Why Google Gemini?

I chose Google Gemini for its structured JSON output capability, which is perfect for generating consistent, type-safe environmental data. The model excels at understanding complex lifestyle patterns and providing nuanced, regional advice.

Technical Implementation

Using Next.js 15 with the App Router and Google's @google/generative-ai SDK, I implemented:

Structured Schema: Defined a TypeScript schema for carbon analysis
Regional Context: Added location-aware recommendations
Difficulty Scoring: Categorized actions by implementation difficulty
Premium UI: Modern glassmorphism design with Tailwind CSS

Challenges Faced

Model naming: Gemini API model versions required experimentation
Structured output validation: Ensuring consistent JSON responses
Regional accuracy: Balancing global averages with local context (e.g., Finland's clean energy grid)

Category Submission

Best Use of Google Gemini - EcoMind showcases Gemini's strength in structured data generation and contextual understanding for environmental impact analysis.

Additional Prize Categories

N/A

EcoMind: AI-Powered Carbon Footprint Analyzer Using Google Gemini

Muhammad Zulqarnain — Sun, 19 Apr 2026 15:31:31 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

EcoMind is a Next.js web application powered by the Google Gemini API that helps users understand and reduce their personal carbon footprint. You describe your daily habits — commute, diet, home energy use, shopping patterns — and Gemini analyzes your lifestyle, estimates your CO₂ impact, and returns a personalized action plan with concrete steps ranked by impact.

The goal was to make environmental awareness feel personal and actionable rather than abstract. Most carbon calculators spit out a number and leave you wondering "so what?" EcoMind closes that gap by combining Gemini's reasoning capabilities with structured output parsing to give context-aware recommendations tailored to your actual situation.

Key features:

Conversational input: Describe your habits in plain language — no rigid forms
Gemini-powered analysis: Uses gemini-1.5-flash to parse lifestyle data, estimate emissions, and generate recommendations
Structured JSON output: Forced JSON schema response from Gemini for reliable rendering
Actionable breakdown: Each recommendation shows estimated CO₂ savings per year
Finland-aware context: Recommendations factor in northern European energy mix and public transit infrastructure

Demo

🔗 Live demo: https://ecomind-coral.vercel.app

You can also run it locally — instructions in the README.

Code

mzunain / ecomind

AI-powered carbon footprint analyzer using Google Gemini - DEV Weekend Challenge Earth Day Edition

EcoMind 🌍

AI-powered carbon footprint analyzer using Google Gemini

Built for the DEV Weekend Challenge: Earth Day Edition

Live Demo

🔗 https://ecomind-gamma.vercel.app

What It Does

EcoMind lets you describe your daily lifestyle in plain language and returns a personalised carbon footprint analysis powered by the Google Gemini API. No rigid forms — just describe your commute, diet, home heating, and travel habits, and get back:

Estimated annual CO₂ in kg
Sustainability score (1–10)
Top 5 reduction actions ranked by impact with CO₂ savings per year
Regional context — advice tailored to your location (Finland-aware by default)

Tech Stack

Next.js 14 (App Router) + TypeScript
Google Gemini API (gemini-1.5-flash) via @google/generative-ai
Structured JSON output using Gemini's responseSchema feature
Tailwind CSS for styling
Vercel for deployment

Getting Started

# Clone the repo
git clone https://github.com/mzunain/ecomind.git
cd ecomind
# Install dependencies
npm install

# Add your Gemini API key
echo '

…

View on GitHub

How I Built It

Tech Stack:

Next.js 14 (App Router) + TypeScript
Google Gemini API (gemini-1.5-flash) via @google/generative-ai SDK
Tailwind CSS for styling
Vercel for deployment

How Gemini is integrated:

The core of EcoMind is a single API route (/api/analyze) that takes a user's lifestyle description and feeds it to Gemini with a carefully engineered system prompt:

const model = genAI.getGenerativeModel({
  model: "gemini-1.5-flash",
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema: ecoAnalysisSchema,
  },
});

const prompt = `
You are an environmental impact expert. Analyze the following lifestyle description
and return a structured carbon footprint assessment.
Lifestyle: ${userInput}
Provide: estimated annual CO2 in kg, top 5 reduction actions with CO2 savings,
and an overall sustainability score (1-10).
`;

const result = await model.generateContent(prompt);

I used Gemini's structured output / JSON schema enforcement feature to guarantee parseable responses — this was the most interesting technical decision. Instead of prompt-engineering my way to consistent JSON, I defined a Zod-like schema and passed it as responseSchema. This made the frontend rendering completely reliable.

Structured output schema:

const ecoAnalysisSchema = {
  type: "object",
  properties: {
    annualCO2Kg: { type: "number" },
    sustainabilityScore: { type: "number" },
    topActions: {
      type: "array",
      items: {
        type: "object",
        properties: {
          action: { type: "string" },
          annualSavingKg: { type: "number" },
          difficulty: { type: "string", enum: ["easy", "medium", "hard"] },
          category: { type: "string" },
        },
      },
    },
    summary: { type: "string" },
  },
};

Why this matters for Earth Day:
Carbon literacy is one of the biggest blockers to individual climate action. People don't act because the data feels distant. By making it conversational and immediate — type a few sentences about your week and get back a personalized plan — EcoMind lowers that barrier significantly.

I also added a Finland-specific context layer because I'm based in Turku and the sustainability advice for someone in the Nordics (excellent public transit, clean energy grid, cold climate heating costs) is genuinely different from generic global advice.

Prize Categories

Best Use of Google Gemini — Gemini is the core engine of EcoMind. The project uses:

gemini-1.5-flash for fast, cost-effective inference
Structured JSON output with response schema for reliable parsing
A multi-part system prompt that grounds Gemini in environmental science context
Dynamic prompt construction based on user input

5 Next.js Performance Patterns That Cut Our Load Time by 60%

Muhammad Zulqarnain — Mon, 13 Apr 2026 06:00:00 +0000

Performance is a feature.

At Quran.com, we serve 50 million users across 200+ countries on varying networks. A 1-second delay for users on slow connections meant people gave up. Every millisecond mattered.

Here are 5 patterns we implemented that cut load time by 60%. With code.

Pattern 1: Font Subsetting

The Problem: We served the full Amiri Arabic font (600KB) on every page. Users on 3G in Southeast Asia waited 4 seconds for the first render.

The Pattern: Subset fonts to only the Unicode ranges actually used on each page.

@font-face {
  font-family: 'Amiri';
  src: url('/fonts/amiri-subset.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0600-06FF, U+200C, U+200D;
}

The Result: Font size: 600KB → 48KB. Load time improvement: 40% on mobile.

pyftsubset Amiri-Regular.ttf --unicodes=0600-06FF,200C,200D --output-file=amiri-subset.woff2

Pattern 2: Incremental Static Regeneration (ISR)

The Problem: 114 surahs with 200+ translations. Full site generation: 45 minutes. Deploys blocked.

export async function getStaticProps(context) {
  const data = await fetchSurahData(context.params.surah);
  return {
    props: { data },
    revalidate: 3600,
  };
}

export async function getStaticPaths() {
  const paths = Array.from({ length: 114 }, (_, i) => ({
    params: { surah: String(i + 1) },
  }));
  return { paths, fallback: 'blocking' };
}

On-demand revalidation:

export default async function handler(req, res) {
  if (req.query.secret !== process.env.REVALIDATE_SECRET) {
    return res.status(401).json({ message: 'Invalid token' });
  }
  await res.revalidate(`/surah/${req.query.surah}`);
  return res.json({ revalidated: true });
}

The Result: Pages cached on CDN, served in <100ms globally.

Pattern 3: Dynamic Imports for Heavy Components

The Problem: Quran player: 350KB bundled. Every user downloads it even if they never use audio.

import dynamic from 'next/dynamic';

const QuranPlayer = dynamic(() => import('@/components/QuranPlayer'), {
  loading: () => <div>Loading player...</div>,
  ssr: false,
});

export default function SurahPage({ data }) {
  const [showPlayer, setShowPlayer] = useState(false);
  return (
    <div>
      <SurahText data={data} />
      {showPlayer && <QuranPlayer surah={data.surah} />}
      <button onClick={() => setShowPlayer(true)}>Play Audio</button>
    </div>
  );
}

Result: 68% of users never click play. They saved the download entirely.

Pattern 4: Image Optimization Pipeline

The Problem: Users upload 3-5MB JPEGs displayed at 120x120px.

import sharp from 'sharp';

export default async function handler(req, res) {
  const buffer = Buffer.from(req.body);
  const webpBuffer = await sharp(buffer).resize(400, 400, { fit: 'cover' }).webp({ quality: 80 }).toBuffer();
  const pngBuffer = await sharp(buffer).resize(400, 400, { fit: 'cover' }).png({ quality: 80 }).toBuffer();
  const webpUrl = await uploadToS3(webpBuffer, 'image.webp');
  const pngUrl = await uploadToS3(pngBuffer, 'image.png');
  res.json({ webpUrl, pngUrl });
}

<picture>
  <source srcSet={image.webpUrl} type="image/webp" />
  <img src={image.pngUrl} alt="User avatar" width={120} height={120} />
</picture>

Result: Images: 3-5MB → 45-80KB.

Pattern 5: Intelligent Prefetching

export function SurahNavigation({ currentSurah }) {
  const router = useRouter();
  const handlePrefetch = () => router.prefetch(`/surah/${currentSurah + 1}`);
  return (
    <Link href={`/surah/${currentSurah + 1}`} onMouseEnter={handlePrefetch} onTouchStart={handlePrefetch}>
      Next Surah
    </Link>
  );
}

Result: Users feel instant navigation. Pages load in <200ms instead of 1-2s.

Before/After

Metric	Before	After	Improvement
First Contentful Paint	3.2s	1.8s	44%
Largest Contentful Paint	4.8s	1.9s	60%
Time to Interactive	6.2s	2.4s	61%
Page Size	2.8MB	1.1MB	61%
Lighthouse Score	42	86	+44 pts

Performance work isn't about micro-optimizations. It's about architectural decisions that compound.

Find me at zunain.com if you're optimizing at scale.

How We Scaled Quran.com to 50M Monthly Users: Architecture Lessons From the Inside

Muhammad Zulqarnain — Sun, 05 Apr 2026 23:21:10 +0000

How We Scaled Quran.com to 50M Monthly Users: Architecture Lessons From the Inside

Scaling a web application to serve 50 million monthly users is not just a technical challenge — it is an architectural one. At Quran.com, one of the world's most visited Islamic resources, I led the frontend engineering effort that took the platform from struggling under load to reliably serving tens of millions of users globally.

Here's what I learned.

Start With the Right Foundation: Next.js and ISR

When I joined the team, Quran.com was running a single-page React app with client-side rendering. Every page load hit the server, every user got the same slow first paint. The fix was a full migration to Next.js with Incremental Static Regeneration (ISR).

ISR lets you pre-render pages at build time and revalidate them in the background on a schedule. For content like Surah pages — which rarely change — we set revalidation to 3600 seconds (1 hour). This meant most users hit pre-rendered HTML instantly instead of waiting for server execution.

Result: Time to first byte dropped by over 70% for users in Asia and the Middle East, where our traffic is heaviest.

Edge Caching: The Second Layer

ISR alone was not enough. We layered Cloudflare in front of Vercel, configured to cache ISR-generated pages at the CDN edge. Users in Riyadh, Karachi, Jakarta — wherever they are — now get pages served from a node close to them.

The configuration that made this work:

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/surah/:id*',
        headers: [
          {
            key: 'Cache-Control',
            value: 'public, s-maxage=3600, stale-while-revalidate=86400'
          }
        ]
      }
    ]
  }
}

The stale-while-revalidate header is the key. It tells the CDN: serve the cached version immediately, and revalidate in the background. Users never wait.

Result: CDN cache hit rate went from ~40% to 92%.

Code Splitting and Bundle Optimization

A 50M-user app cannot afford bloated JavaScript bundles. We audited every dependency and applied aggressive code splitting:

Dynamic imports for heavy components (audio player, translation viewer)
Route-based splitting via Next.js dynamic routing
Moving user preferences (theme, language settings) to client-side state to avoid cache busting on every personalized request

Result: Initial JS bundle size reduced by ~45%.

What Scaling Actually Teaches You

The biggest lesson from working at this scale: the architecture decisions that seem like premature optimization are often the decisions that matter most.

ISR is not a performance trick — it is a scalability strategy. At 50 million users, every millisecond you shave off the critical path compounds. A 100ms improvement in TTFB means millions of users per day load faster, engage more, and return more often.

If you are building a content-heavy Next.js application, do not wait until you have scale problems to think about ISR and edge caching. Build it right the first time.

The Stack at a Glance

Framework: Next.js 14 (App Router, ISR)
CDN: Cloudflare
Deployment: Vercel
State: React Query + Zustand
Languages: TypeScript throughout

If you have questions about scaling Next.js in production or want to talk architecture, reach out at zunain.com.

Building a Production RAG Pipeline: Lessons from Real-World AI Apps

Muhammad Zulqarnain — Sun, 05 Apr 2026 19:23:37 +0000

Building a Production RAG Pipeline: Lessons from Real-World AI Apps

RAG (Retrieval-Augmented Generation) sounds simple on paper — embed your documents, store them in a vector DB, retrieve the relevant chunks, and pass them to an LLM. In practice, getting a RAG pipeline to production quality is significantly harder.

Here's what I learned building RAG pipelines for real SaaS products.

The Naive Implementation

Most tutorials show you this flow:

Chunk your documents
Embed them with OpenAI
Store in Pinecone
Retrieve top-k chunks
Pass to GPT-4

This works fine in demos. It fails in production for a few key reasons.

Problem 1: Chunking Strategy Kills Retrieval Quality

Naive fixed-size chunking (every 512 tokens) destroys semantic context. A paragraph about "authentication" gets split mid-sentence, and your retrieval picks up half-relevant chunks.

What works: Semantic chunking — split at natural sentence and paragraph boundaries, and use overlapping windows so context carries across chunk boundaries.

def semantic_chunk(text, chunk_size=500, overlap=50):
    sentences = split_into_sentences(text)
    chunks = []
    current_chunk = []
    current_length = 0

    for sentence in sentences:
        if current_length + len(sentence) > chunk_size:
            chunks.append(' '.join(current_chunk))
            # Keep last N tokens as overlap
            current_chunk = current_chunk[-overlap:]
            current_length = sum(len(s) for s in current_chunk)
        current_chunk.append(sentence)
        current_length += len(sentence)

    return chunks

Problem 2: Top-K Retrieval Without Re-ranking

Retrieving the top 5 chunks by cosine similarity often misses the point. The 6th most similar chunk might be the most relevant one in context.

What works: Two-stage retrieval — retrieve top 20 by vector similarity, then re-rank with a cross-encoder model (or GPT-4 itself) to get the final top 5.

Problem 3: No Caching = Expensive at Scale

Every query hitting your vector DB and LLM is a cost. At scale, you'll see the same semantic queries repeatedly.

What works: Semantic caching — hash the embedding of each query and cache results for similar queries (cosine similarity > 0.97).

The Production Stack That Works

Embeddings: OpenAI text-embedding-3-large (best quality/cost)
Vector DB: Pinecone (managed, scales easily) or Weaviate (self-hosted, more control)
Re-ranking: Cohere Rerank API or a local cross-encoder
Caching: Redis with embedding-based similarity check
LLM: GPT-4o for quality, GPT-4o-mini for speed/cost tradeoff

Key Takeaway

Production RAG is 20% architecture and 80% data quality + retrieval tuning. The chunking and retrieval strategy matter more than the LLM choice.

What's been your biggest challenge with RAG in production? Drop it in the comments.

How We Scaled Quran.com to 50M+ Monthly Users: Architecture Lessons from the Inside

Muhammad Zulqarnain — Sat, 04 Apr 2026 20:08:55 +0000

Quran.com is one of the most-visited Islamic websites in the world. During my time there as a Full Stack Engineer, the platform crossed 50 million monthly active users — a milestone that forced us to rethink nearly every assumption we'd made about architecture, data, and performance.

This post covers the technical decisions that got us there, the tradeoffs we made, and what I'd do differently.

The Scale Reality

50M MAU sounds like an abstract number. In practice it means spikes of hundreds of thousands of concurrent users during Ramadan, Quran audio files being streamed from every continent simultaneously, prayer time calculations for locations across the entire globe, and serving both high-bandwidth users in the West and users on 2G/3G connections in South Asia and Sub-Saharan Africa.

That last point shaped almost every technical decision. You can't optimize purely for fast connections. You have to think about the user opening the site on a 2G connection in rural Pakistan at 3am for Fajr prayer.

Frontend: Next.js as the Foundation

We built on Next.js. Server-side rendering was critical for two reasons: SEO (the Quran text needs to be indexable) and first-load performance on slow connections. Each Surah page (114 in total) is statically generated at build time — meaning the first HTML response is near-instant, no waiting for JS to hydrate before the user sees text.

We were aggressive about code splitting: audio player logic only loads when the user actually interacts with audio. Next.js Image with AVIF/WebP fallback cut image payloads significantly while staying compatible with older devices.

Offline Audio Streaming

One of the most technically interesting problems: how do you let a user listen to Quran recitations with no internet?

Quran audio is broken into individual ayah (verse) recordings — up to 6,236 of them per reciter. You can't cache all of that upfront. Our solution: when a user starts playing a Surah, we silently prefetch the next 10 ayahs in the background using Service Workers and the Cache API. If connectivity drops, playback continues seamlessly. We also gave users an explicit "Download for offline" option for Surahs they listen to regularly.

Geospatial: Prayer Times at Scale

Prayer times are calculated based on GPS coordinates — simple until you consider DST rules that differ by country, multiple calculation methodologies (Hanafi, Shafi'i, MWL, ISNA), and users who want accurate times regardless of whether they share their location.

We moved prayer time calculation to the client side. The astronomy math runs in under a millisecond on any modern device, requires no server round-trip, and stores no user location data.

For map-based features — nearby mosques, Qibla direction — we used Mapbox GL JS. The vector tile approach is ideal: compact, cacheable, and sharp at any zoom level.

Database and Infrastructure

PostgreSQL was our primary data store. The Quran text is relational in nature — verses have translations, tafsirs, word-by-word breakdowns, audio timestamps, and cross-references. A relational model maps cleanly to this structure.

For our read-heavy endpoints (almost all of them), we leaned on read replicas to distribute query load, Redis for caching frequently-accessed data, and aggressive CDN caching at the edge for static API responses.

Infrastructure ran on AWS: ECS for containerized services, RDS for PostgreSQL, ElastiCache for Redis, CloudFront as CDN.

What I'd Do Differently

Invest in observability earlier. We added distributed tracing later than we should have. When you're debugging a latency spike that only affects users in a specific region, you want granular trace data — not logs.

Be more aggressive with edge caching. Many API responses could have been fully cached at the CDN layer, eliminating server load for the vast majority of requests. We were conservative about this early and paid the price during Ramadan traffic spikes.

Design for low-bandwidth from day one. We retrofitted a lot of optimizations later. Starting with that constraint leads to better decisions upfront — smaller bundles, progressive loading, offline-first thinking baked in from the beginning.

Closing Thoughts

Working on a platform where the content matters deeply to hundreds of millions of people sharpens your instincts. Performance isn't vanity. A 3-second improvement in load time is the difference between someone completing Fajr prayer with the app or giving up.

If you're working on similar challenges — high-scale web apps, geospatial features, or offline-capable PWAs — find me at zunain.com or on GitHub at mzulqarnain118.

Next.js Production Apps: Server Components and API Routes

Muhammad Zulqarnain — Tue, 20 Jan 2026 08:00:00 +0000

Next.js has become my framework of choice for building production-ready full-stack applications. Here's how I leverage its powerful features.

Why Next.js?

Complete Full-Stack Solution

Server and client components
Built-in API routes
Automatic code splitting
Optimized image handling
SEO-friendly by default

Server Components (App Router)

// app/page.tsx
import { getProducts } from '@/lib/data';

export default async function HomePage() {
  const products = await getProducts();

  return (
    <main>
      <h1>Products</h1>
      {products.map(product => (
        <ProductCard key={product.id} product={product} />
      ))}
    </main>
  );
}

API Routes

// app/api/products/route.ts
import { NextResponse } from 'next/server';
import { db } from '@/lib/db';

export async function GET() {
  try {
    const products = await db.product.findMany();
    return NextResponse.json(products);
  } catch (error) {
    return NextResponse.json(
      { error: 'Failed to fetch products' },
      { status: 500 }
    );
  }
}

export async function POST(request: Request) {
  const body = await request.json();
  const product = await db.product.create({ data: body });
  return NextResponse.json(product);
}

Data Fetching Patterns

// Server Component - Direct database access
async function getUser(id: string) {
  const user = await db.user.findUnique({ where: { id } });
  return user;
}

// With caching
import { unstable_cache } from 'next/cache';

const getCachedProducts = unstable_cache(
  async () => db.product.findMany(),
  ['products'],
  { revalidate: 3600 }
);

My Production Setup

✅ Performance

Image optimization with next/image
Font optimization
Bundle analyzer

✅ SEO

Metadata API
Sitemap generation
robots.txt

✅ Developer Experience

TypeScript throughout
ESLint & Prettier
Tailwind CSS

Next.js simplifies full-stack development while maintaining excellent performance and SEO. The App Router and Server Components have transformed how I build web applications.

React Native Performance: Building High-Performance Mobile Apps

Muhammad Zulqarnain — Sun, 18 Jan 2026 08:00:00 +0000

React Native has transformed how I build mobile applications, enabling true cross-platform development while maintaining near-native performance. Here's my experience and the practices that have made my React Native projects successful.

Why React Native?

Single Codebase, Multiple Platforms

Share 80-90% of code between iOS and Android
Faster development cycles
Consistent user experience across platforms
Lower maintenance costs

Performance Optimization Techniques

1. Optimize Re-renders

import React, { memo, useCallback } from 'react';

const ProductCard = memo(({ product, onPress }) => {
  return (
    <TouchableOpacity onPress={() => onPress(product.id)}>
      <Text>{product.name}</Text>
      <Text>${product.price}</Text>
    </TouchableOpacity>
  );
});

export default ProductCard;

2. FlatList Optimization

<FlatList
  data={products}
  renderItem={renderProduct}
  keyExtractor={item => item.id}
  removeClippedSubviews={true}
  maxToRenderPerBatch={10}
  updateCellsBatchingPeriod={50}
  initialNumToRender={10}
  windowSize={10}
  getItemLayout={(data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  })}
/>

3. Image Optimization

import FastImage from 'react-native-fast-image';

<FastImage
  source={{
    uri: imageUrl,
    priority: FastImage.priority.normal,
    cache: FastImage.cacheControl.immutable
  }}
  resizeMode={FastImage.resizeMode.cover}
/>

Architecture Best Practices

State Management with Redux Toolkit

import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';

export const fetchProducts = createAsyncThunk(
  'products/fetch',
  async (category) => {
    const response = await api.getProducts(category);
    return response.data;
  }
);

const productsSlice = createSlice({
  name: 'products',
  initialState: { items: [], loading: false },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchProducts.pending, (state) => {
        state.loading = true;
      })
      .addCase(fetchProducts.fulfilled, (state, action) => {
        state.items = action.payload;
        state.loading = false;
      });
  },
});

Navigation Structure

import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';

const Stack = createNativeStackNavigator();

function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator screenOptions={{ headerShown: false }}>
        <Stack.Screen name="Home" component={HomeScreen} />
        <Stack.Screen name="Product" component={ProductScreen} />
        <Stack.Screen name="Cart" component={CartScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

Native Modules Integration

When you need platform-specific functionality:

import { NativeModules, Platform } from 'react-native';

const { BiometricAuth } = NativeModules;

const authenticateUser = async () => {
  if (Platform.OS === 'ios') {
    return await BiometricAuth.authenticateWithFaceID();
  } else {
    return await BiometricAuth.authenticateWithFingerprint();
  }
};

Production Deployment Tips

✅ Performance

Enable Hermes engine for faster startup
Use ProGuard/R8 for Android code shrinking
Optimize bundle size with Metro bundler

✅ Testing

Unit tests with Jest
E2E tests with Detox
Visual regression testing

✅ Monitoring

Integrate Sentry for crash reporting
Use React Native Performance monitoring
Track bundle size metrics

My Experience

Building mobile apps with React Native has allowed me to deliver high-quality applications faster than traditional native development. The key is understanding when to use native modules for performance-critical features while leveraging JavaScript for business logic.

The React Native ecosystem continues to evolve, and with tools like Expo, the developer experience has never been better.

What's your experience with React Native? Share your optimization tips in the comments!

Enterprise-Grade Node.js with NestJS: Building Scalable Backend Architecture

Muhammad Zulqarnain — Sat, 17 Jan 2026 08:00:00 +0000

NestJS has become my go-to framework for building enterprise Node.js applications. Here's why it stands out and how I leverage it in production.

Why NestJS?

TypeScript-First Approach

Strong typing catches bugs at compile time
Better IDE support and autocomplete
Enhanced code documentation

Architecture Patterns

NestJS embraces proven design patterns:

Dependency Injection: Clean, testable code
Modular Structure: Organized codebase
Decorators: Readable, declarative code

Core Features I Use Daily

1. Controllers & Services

@Controller('users')
export class UsersController {
  constructor(private usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

2. Middleware & Guards

Authentication guards
Role-based access control
Request validation pipes

3. Built-in Features

✅ Microservices support out of the box
✅ GraphQL integration
✅ WebSockets for real-time features
✅ Testing utilities built-in
✅ OpenAPI documentation

Production Best Practices

Configuration Management

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      validate: environmentValidation
    })
  ]
})

Database Integration

TypeORM for relational databases
Mongoose for MongoDB
Prisma for modern ORM

Error Handling

Exception filters for global error handling
Custom exceptions for business logic
Proper HTTP status codes

My Experience

Building microservices with NestJS reduced our development time by 40%. The framework's opinionated structure ensures consistency across teams.

Are you using NestJS? What's your favorite feature?

NestJS #NodeJS #TypeScript #Backend

Building Scalable REST APIs with Node.js and Express: Production Best Practices

Muhammad Zulqarnain — Fri, 16 Jan 2026 08:00:00 +0000

After years of building production Node.js applications, I've learned that scalability isn't just about handling more requests—it's about architectural decisions made from day one.

Essential Architecture Patterns

1. Layered Architecture

Controllers: Handle HTTP requests
Services: Business logic layer
Repositories: Data access layer

This separation ensures testability and maintainability as your API grows.

2. Error Handling

// Centralized error handling middleware
app.use((err, req, res, next) => {
  logger.error(err);
  res.status(err.status || 500).json({
    error: err.message
  });
});

3. Performance Optimization

Caching: Implement Redis for frequently accessed data
Rate limiting: Protect against abuse
Compression: Use gzip middleware
Database indexing: Optimize query performance

4. Security Best Practices

Helmet.js for HTTP headers
Input validation with Joi
JWT for authentication
CORS configuration

Production Checklist

✅ Environment variables for configuration
✅ Logging with Winston or Pino
✅ Health check endpoints
✅ Graceful shutdown handling
✅ API documentation (Swagger/OpenAPI)
✅ Monitoring and alerts

My Experience

Building REST APIs that serve millions of requests taught me that premature optimization is real, but so is technical debt. Start with clean architecture, add optimizations based on actual metrics.

What's your biggest Node.js API challenge?

NodeJS #Express #Backend #JavaScript #API