Forem: Saad Mehmood

Next.js API Routes: Patterns That Scale

Saad Mehmood — Mon, 06 Apr 2026 05:36:29 +0000

Next.js API routes are quick to add but easy to outgrow. Here are patterns I use to keep them maintainable as the app grows.

1. Centralized Error Handling

Don’t repeat try/catch and status codes in every route. Use a small wrapper or middleware:

// lib/api-handler.ts (concept)
export function withErrorHandling(
  handler: (req: NextRequest) => Promise<Response>
) {
  return async (req: NextRequest) => {
    try {
      return await handler(req);
    } catch (error) {
      console.error(error);
      return NextResponse.json(
        { error: 'Internal Server Error' },
        { status: 500 }
      );
    }
  };
}

Use it so each route focuses on success logic; errors are handled in one place.

2. Validate Input

Validate query and body with Zod (or Yup). Return 400 with clear messages instead of blowing up later:

const schema = z.object({
  page: z.coerce.number().min(1).default(1),
  perPage: z.coerce.number().min(1).max(100).default(15),
});

const parsed = schema.safeParse(Object.fromEntries(req.nextUrl.searchParams));
if (!parsed.success) {
  return NextResponse.json(
    { error: parsed.error.flatten() },
    { status: 400 }
  );
}
const { page, perPage } = parsed.data;

Same idea for POST/PUT body: parse JSON, then validate with Zod.

3. Use the Right HTTP Methods and Status Codes

GET — read; idempotent. Use 200 (with body) or 204 (no body).
POST — create. Return 201 and Location header when you create a resource.
PUT/PATCH — update. 200 with body or 204.
DELETE — 204 on success.

Return 400 for bad input, 401 for unauthenticated, 403 for forbidden, 404 when the resource doesn’t exist, 429 when rate-limited.

4. Cache Where It Makes Sense

For public or semi-static data, use Next.js caching:

export const revalidate = 60; // ISR: revalidate every 60 seconds
// or
export const dynamic = 'force-static';

For user-specific or private data, avoid caching or use short revalidation and proper auth checks.

5. Move Logic Out of the Route File

Keep route.ts thin: parse request, validate, call a service, return response. Put business logic in lib/ or services/ so you can test and reuse it. Same for DB access: use a repo or client in lib/, not raw queries in the route.

6. Auth and Rate Limiting

Check auth (e.g. session or JWT) in middleware or at the start of the handler. Return 401/403 early.
Add rate limiting (e.g. Upstash Redis or a simple in-memory store) on public or sensitive endpoints so one client can’t overwhelm the API.

These patterns keep API routes readable and consistent as you add more endpoints and team members.

Saad Mehmood — Portfolio

Building Real-Time Features with Firebase (or Supabase) in React Native

Saad Mehmood — Mon, 06 Apr 2026 05:34:52 +0000

Real-time updates—chat, live data, presence—are common in mobile apps. Here’s how I approach them with Firebase or Supabase in React Native.

Why Firebase or Supabase?

Both give you:

Realtime listeners — Subscribe to a path or query; get updates when data changes.
Auth — So you can secure data per user.
Offline — Firebase has built-in persistence; Supabase can work with local SQLite or similar.

I use Firebase when the team already uses it or needs other Google services; Supabase when we want Postgres and a more SQL-friendly API.

Firebase Firestore: Realtime Listeners

// Subscribe to a collection or query
const unsubscribe = firestore()
  .collection('chats')
  .doc(chatId)
  .collection('messages')
  .orderBy('createdAt', 'desc')
  .limit(50)
  .onSnapshot(
    (snapshot) => {
      const messages = snapshot.docs.map(doc => ({
        id: doc.id,
        ...doc.data(),
      }));
      setMessages(messages);
    },
    (error) => {
      // Handle errors, show user-friendly message
    }
  );

// Cleanup on unmount
return () => unsubscribe();

Tips:

Use limit() and paginate; don’t load entire collections.
Enable offline persistence so the app works without network.
Secure with Firestore rules: validate request.auth and restrict reads/writes by user or role.

Supabase: Realtime with Postgres

const channel = supabase
  .channel('messages')
  .on(
    'postgres_changes',
    {
      event: 'INSERT',
      schema: 'public',
      table: 'messages',
      filter: `chat_id=eq.${chatId}`,
    },
    (payload) => {
      setMessages(prev => [payload.new, ...prev]);
    }
  )
  .subscribe();

return () => {
  supabase.removeChannel(channel);
};

You get realtime from Postgres changes (insert/update/delete). Enable Realtime on the tables you need in the Supabase dashboard.

Auth First

Both platforms tie data to users. Ensure:

User is signed in before subscribing.
Listeners are scoped to the current user (e.g. userId in the path or filter).
On auth state change, unsubscribe from old listeners and subscribe with the new user.

Offline and UX

Show a “connecting” or “offline” indicator when the client is disconnected.
Queue critical actions (e.g. send message) and retry when back online.
For Firebase, use persistence; for Supabase, consider local caching (e.g. React Query + persistence) for a smooth offline experience.

Real-time doesn’t have to mean “complex.” Start with one collection or table, get the listener and cleanup right, then expand from there.

Saad Mehmood — Portfolio

Improve React Native App Security: 10 Practices to Evaluate Your Project

Saad Mehmood — Wed, 11 Mar 2026 15:31:58 +0000

After working with React Native for several years, I've put together key security practices you can use to evaluate your project. Apps can't be 100% secure, but you can make hacking difficult and expensive. Here's a checklist that covers the main attack surfaces and what to do about them.

1. SSL Pinning

Problem: API calls can be intercepted with tools like Burp Suite or Charles Proxy, exposing request payloads and responses—including tokens and sensitive data.

Solution: Implement certificate pinning so the app only trusts your server's certificate (or public key). That way, even if someone installs a custom CA, man-in-the-middle traffic won't be accepted.

Use react-native-ssl-pinning (or a similar library) to pin your API domain. Pin the certificate or public key hashes and fail closed if they don't match. Remember to update pins before cert rotation so the app doesn't break.

2. Reverse Engineering

Problem: APK (Android) and IPA (iOS) can be decompiled using tools like APKTool, jadx, or Hopper, revealing business logic, API shapes, and sometimes secrets.

Solution:

Android: Enable ProGuard or R8 in release builds to obfuscate and shrink code. Remove debug symbols and strip unnecessary metadata.
iOS: Strip symbols in release builds (Xcode does this by default when you build for release). Avoid storing secrets or critical logic in the client when possible.
General: Move sensitive logic and decisions to the backend. Treat the client as untrusted; validate and authorize on the server.

3. Secure Local Storage

Problem: AsyncStorage (and similar unencrypted storage) can be read on rooted (Android) or jailbroken (iOS) devices, leaking tokens and other sensitive data.

Solution: Use platform-backed secure storage:

iOS: Keychain (encrypted, tied to the device and optionally to biometrics).
Android: Keystore (hardware-backed when available).

Libraries like react-native-keychain or react-native-encrypted-storage expose a single API for both platforms. Store tokens, refresh tokens, and other secrets there—not in AsyncStorage or plain files.

4. Screenshot / Screen Recording

Problem: Sensitive screens (OTP, payment forms, private content) can be captured via screenshots or screen recording and leak outside the app.

Solution:

Android: Prevent screenshots on sensitive screens using FLAG_SECURE (or packages like react-native-screenshot-prevent) so the system doesn't allow screenshots or recording of that window.
iOS: Detect screen recording using UIScreen.isCaptured and hide or blur sensitive views (e.g. OTP field, card number) while recording is active.

Tip: react-native-screen-capture-secure can help detect and block screen capture on both platforms. Use it on screens that show PII, payment details, or one-time codes.

5. Root / Jailbreak Detection

Problem: Rooted (Android) or jailbroken (iOS) devices can bypass app protections, read memory or storage, and tamper with the runtime.

Solution: Detect compromised devices using a library like react-native-jail-monkey (or similar). Use the result to:

Block access entirely for high-risk apps (e.g. banking), or
Limit features / show a warning and log the event for analytics.

Balance security with UX: some users root for legitimate reasons, so define a clear policy (block vs. warn vs. allow with reduced functionality).

6. Code Obfuscation

Problem: The JS bundle and native code can be inspected to extract API keys, endpoints, or business logic.

Solution:

JavaScript: Use javascript-obfuscator (or a Metro/bundler plugin that integrates it) to obfuscate the release bundle. Don't rely on obfuscation to protect real secrets—move those to the backend or use short-lived tokens.
Native: On Android, ProGuard/R8 obfuscate Java/Kotlin. On iOS, strip symbols and avoid embedding secrets in the binary. Obfuscation raises the bar; it doesn't make reverse engineering impossible.

7. API Security

Problem: Exposed API keys, long-lived tokens, or unvalidated requests can be abused by attackers who extract them from the app or intercept traffic.

Solution:

Use short-lived tokens (e.g. JWT with short expiry) and refresh them via a secure, authenticated flow. Don't put long-lived API keys in the client if they can be moved to the backend.
Validate every request on the backend—auth, authorization, and input validation. Never trust the client.
Optionally sign payloads (e.g. HMAC) for critical operations so the server can detect tampering.

8. Runtime Integrity / Tamper Detection

Problem: The APK or IPA can be modified (re-signed, patched) to bypass checks, remove root detection, or inject code.

Solution: Verify app signature (and optionally integrity) at runtime:

Android: Check that the app is signed with your release keystore (e.g. compare signature to a known value).
iOS: The system enforces code signing; you can add checks for jailbreak and for tampering with key resources.

If the app appears modified or running in an unexpected environment, block or limit functionality and report. This makes casual tampering harder; determined attackers may still find ways around it.

9. Secure Deep Links

Problem: Malicious apps or links can trigger your deep links with crafted parameters and try to open sensitive screens (e.g. password reset, payment) without proper auth.

Solution:

Validate all parameters—type, format, and allowed values. Reject or sanitize anything suspicious.
Authenticate the user before opening sensitive screens. Don't rely on the link alone to grant access; verify session or token on the server if needed.
Use verified app links (Android App Links / iOS Universal Links) so only your domain can open your app, reducing phishing via custom URL schemes.

10. CodePush / OTA Updates

Problem: Over-the-air updates (e.g. CodePush, EAS Update) can deliver new JS (and sometimes assets). If the update channel or signing isn't enforced, an attacker could push malicious code to users.

Solution:

Only allow signed updates from your own backend or the official CodePush/EAS endpoint. Verify the signature or token before applying an update.
Verify the source of the update (e.g. same app ID, same deployment key) and use HTTPS and certificate pinning for the update endpoint.
Restrict who can publish updates and audit release history. Treat OTA as a privileged pipeline.

Summary

#	Area	Main risk	Key mitigation
1	SSL	MITM, traffic interception	Certificate/public key pinning
2	Reverse engineering	Logic and secrets exposed	ProGuard/R8, strip symbols, move logic to backend
3	Local storage	Token/data leak on compromised devices	Keychain / Keystore (react-native-keychain, etc.)
4	Screenshot/recording	Sensitive UI captured	FLAG_SECURE, UIScreen.isCaptured, blur/hide
5	Root/jailbreak	Bypass of app protections	Detect and block or limit (e.g. react-native-jail-monkey)
6	Code obfuscation	Keys and logic extracted	JS obfuscator, ProGuard/R8; no secrets in client
7	API	Abuse of keys and endpoints	Short-lived tokens, server-side validation, signing
8	Runtime integrity	Tampered app bypasses checks	Signature verification, tamper detection
9	Deep links	Unauthorized access to screens	Validate params, authenticate user
10	OTA updates	Malicious update delivery	Signed updates only, verify source

Use this list to review your React Native app and prioritize the items that matter most for your data and threat model. If you've got practices that have worked well for you, share them in the comments.

Saad Mehmood — Portfolio | Dev.to

React Native Performance: What I Measure and Fix First

Saad Mehmood — Tue, 17 Feb 2026 09:39:10 +0000

When a React Native app feels slow, it’s easy to guess. Here’s what I measure first and the fixes I reach for most often.

What I Measure

Startup time — Time from tap to first meaningful paint (e.g. home screen visible). I use Flipper, React Native’s built-in perf tools, or a simple timestamp in native code. I compare before/after changes (e.g. new libs, more initial data) so we don’t regress.

Frame rate (FPS) — Especially on scroll and animation. React Native’s “Show Perf Monitor” or Flipper shows JS and UI thread FPS. Drops below 60 (or 120 on capable devices) mean jank. I note which screen or list causes it.

List scroll — Long lists are a common bottleneck. I check: Are we using FlatList (or similar)? Are we rendering too many items or heavy components per row? Are we doing work on the JS thread during scroll?

Memory — I watch for leaks (memory growing over time) and big allocations. Flipper or Xcode/Android Studio profilers show what’s growing. Often it’s images, caches, or listeners not cleaned up.

Bundle size — Large JS bundles slow startup. I check the output of the build (e.g. npx react-native bundle --dev false and inspect size). I look for heavy dependencies that could be lazy-loaded or replaced.

I don’t optimize everything—I focus on startup and the screens users hit most (e.g. home, main list). Fix the biggest wins first.

Baseline per release — Track a small set of numbers per release (e.g. startup time, list FPS on the main feed, memory after 5 minutes). Store them in a doc or CI. When a new feature lands, compare against the baseline so regressions are obvious instead of “it feels slower.”

Fixes I Reach For First

Lists — Use FlatList (or FlashList if we need more throughput). Implement getItemLayout when item height is fixed so we skip measurement. Use windowSize and maxToRenderPerBatch to limit how many items are in the tree. Memoize list item components so they don’t re-render on every scroll tick. Avoid inline functions and object literals in renderItem; pass stable props.

Images — Use resizeMode appropriately. Serve correctly sized images from the backend or use a CDN that resizes. Consider react-native-fast-image for caching if the default cache isn’t enough. Lazy-load off-screen images in lists.

Re-renders — Find unnecessary re-renders with React DevTools Profiler or “Highlight updates.” Often the fix is: memoize components (React.memo), stabilize callbacks (useCallback) and objects/arrays (useMemo), or lift state so only the part that needs to re-render does. Avoid setting state in render or in effects that run too often.

JS thread — Move heavy work off the JS thread: use native modules for heavy computation, or do work in batches (e.g. InteractionManager.runAfterInteractions). Don’t do large sync operations on the main JS thread during startup or scroll.

Startup — Reduce initial JS: lazy-load screens (e.g. React.lazy + code splitting where supported), defer non-critical imports, and trim dependencies. Use Hermes if you’re not already; it often improves startup and memory.

Cleanup — Unsubscribe from listeners, clear timers, and cancel requests in useEffect cleanup. Remove event listeners and close connections so we don’t leak memory or keep unnecessary work running.

I fix one area at a time, measure again, and repeat. Small, verified improvements add up; random “optimizations” without measurement often don’t.

Saad Mehmood — Portfolio

From MVP to Production: A React Native Checklist

Saad Mehmood — Tue, 17 Feb 2026 09:18:09 +0000

You've built the features. The app works on your machine. Now what?

The gap between "it works on my machine" and "it's live in the store and we can maintain it" is where a lot of projects get stuck—or ship anyway and pay for it later with broken builds, wrong environments, and "why is staging hitting production?" incidents. After shipping multiple React Native apps to the stores (including large-scale event apps), I've learned that a small set of habits and checks makes that transition predictable instead of painful.

This post is the checklist I use for every new app and the one I recommend when joining a project that's about to go to production. It's not exhaustive—you'll add items for your stack and compliance needs—but it's the baseline that keeps builds, environments, and releases under control. Use it as a starting point and tighten each area as the product and team grow.

Environment & Config

Getting environment and build variants right early avoids the classic mistakes: hardcoded API URLs, staging builds accidentally talking to production, and "it worked in debug but not in release." Spend a little time here and the rest of the pipeline stays sane.

[ ] Environment variables — Use react-native-config or Expo's env scheme so API URLs, feature flags, and keys live outside the codebase. Never hardcode them. Have separate configs for dev, staging, and prod so each build talks to the right backend and you can change URLs without a new app release.
[ ] Build variants — Android: product flavors. iOS: schemes + configurations. Ensure each variant points to the right API and config (see below).
[ ] Versioning — Bump versionCode (Android) and CFBundleShortVersionString / CFBundleVersion (iOS) for every release. Store submissions reject duplicate version numbers, and users (and crash reports) need to know which build they're on. Consider automating bumps in CI so you never ship the same version twice.

Product flavors (Android) and schemes (iOS) — Dev, Staging, Production

Use separate build variants so you can install dev, staging, and production on the same device and keep API/env configs isolated.

Android — Product flavors

In android/app/build.gradle, define flavors and wire them to env (e.g. react-native-config or BuildConfig):

android {
    flavorDimensions += "environment"
    productFlavors {
        dev {
            dimension = "environment"
            applicationIdSuffix = ".dev"
            versionNameSuffix = "-dev"
            resValue "string", "app_name", "MyApp Dev"
            buildConfigField "String", "API_BASE_URL", "\"https://api-dev.example.com\""
        }
        staging {
            dimension = "environment"
            applicationIdSuffix = ".staging"
            versionNameSuffix = "-staging"
            resValue "string", "app_name", "MyApp Staging"
            buildConfigField "String", "API_BASE_URL", "\"https://api-staging.example.com\""
        }
        production {
            dimension = "environment"
            resValue "string", "app_name", "MyApp"
            buildConfigField "String", "API_BASE_URL", "\"https://api.example.com\""
        }
    }
}

dev — .dev suffix so it installs alongside staging/prod. Use dev API and debug-friendly app name.
staging — .staging suffix, staging API. Use for QA and pre-release testing.
production — No suffix; this is the store build. Production API only.

Build with: npx react-native run-android --variant=devDebug (or stagingRelease, productionRelease, etc.).

iOS — Schemes and configurations

Configurations — In Xcode, duplicate Debug and Release (e.g. Debug-Dev, Release-Staging, Release-Production) or use xcconfig files that set API_BASE_URL and other env per configuration.
Schemes — Create schemes Dev, Staging, Production. In each scheme, set the Run and Archive actions to use the right configuration (e.g. Dev → Debug-Dev; Staging → Release-Staging; Production → Release).
Bundle ID suffix — In the project’s Build Settings (or per configuration), set Product Bundle Identifier so dev/staging have a suffix (e.g. com.yourapp.dev, com.yourapp.staging). That lets you install dev, staging, and production side by side.
Display name — Set Display Name per configuration (e.g. “MyApp Dev”, “MyApp Staging”) so you can tell them apart on the home screen.

Run with: Product → Scheme → Dev (or Staging/Production), then Run or Archive.

Expo

If you use EAS and app.config.js, use environment (or APP_ENV) and different extra / env in eas.json profiles (e.g. development, preview, production) so each build gets the correct API URL and app name. You can still use dev-client builds for dev/staging and production builds for the store.

Testing (Minimum Viable)

You don't need 100% coverage on day one—but you do need a safety net for the paths that matter. The goal here is to catch regressions before they reach users and to validate the build you're actually going to submit, not just the debug one.

[ ] Critical flows — At least one E2E or integration test for login/signup and the main user journey. Detox or Maestro can run in CI.
[ ] No obvious regressions — Manual test on at least one physical device per platform before release.
[ ] Release build — Test the exact build you’ll submit (not just debug). ProGuard/minification can hide bugs.

CI/CD

Store builds should come from a repeatable pipeline, not from someone's laptop. That means builds run in the cloud, signing is managed in one place, and submission to TestFlight or Play is a step in the pipeline—not a manual upload after "it built on my machine."

[ ] Builds in the cloud — Use EAS Build, Bitrise, GitHub Actions, or similar so every build runs in the same environment. No "it works on my machine" for store builds; if the pipeline passes, the build is reproducible and auditable.
[ ] Signing — Android: keystore stored securely (e.g. in CI secrets or a secrets manager), never in the repo. iOS: certificates and provisioning managed in Apple Developer and wired through EAS or Fastlane so the build step doesn't depend on a single Mac or keychain.
[ ] Automated submit — After a successful build, automatically submit to TestFlight and Play Internal Testing (e.g. via Fastlane or EAS Submit). Optionally, trigger production submission on a specific tag or branch so releases are traceable and consistent.

Store & Compliance

Stores and regulators care about privacy, permissions, and clear communication. Getting this right up front avoids rejections and builds trust with users.

[ ] Privacy — Provide a privacy policy URL and accurate data collection disclosure in App Store Connect and Play Console. If you use analytics, crash reporting, or third-party SDKs that collect data, say so. Vague or missing disclosures can lead to rejection or legal risk.
[ ] Permissions — Request only the permissions you actually need, and explain why in permission rationale strings (Android) and Info.plist usage descriptions (iOS). Users are more likely to grant access when they understand the reason; stores may reject apps that ask for broad permissions without justification.
[ ] Store assets — Screenshots, description, and keywords affect discoverability and conversion. Invest in clear copy and representative screenshots. If you care about install rates, consider A/B testing store assets (where the platform allows) to see what resonates.

Observability

Once the app is live, you need to know when it breaks and how it behaves. Without crash reporting and some visibility into usage, you're flying blind—and users will tell you about bugs before your metrics do.

[ ] Crash reporting — Integrate Firebase Crashlytics, Sentry, or similar so every crash generates a report with stack trace and device info. Crashes should create issues (or alerts), not go unnoticed. Triage and fix high-impact crashes before they accumulate bad reviews.
[ ] Analytics — Track key events that matter for product decisions: signup, purchase, core actions. Don’t over-instrument; focus on events you'll actually use to understand funnels and behavior. Too many events add noise and can complicate privacy compliance.
[ ] Performance — Monitor startup time and key screens (e.g. time to interactive, list scroll performance). Set a baseline and fix big regressions before they hit production. Slow apps get uninstalled; catching regressions in staging or beta keeps production healthy.

Documentation

Good docs reduce "how do I run this?" and "how do we release?" to a few minutes instead of a day of digging. They also make it possible for someone else to own the release when you're not around.

[ ] README — Document how to install dependencies, run the app locally, and build for dev/staging/prod (including which variant or scheme to use). A new team member should be able to get the app running from the README alone, without tribal knowledge.
[ ] Runbook — Document how to cut a release: which branch or tag to use, how to trigger the CI build, and how to promote from TestFlight/Internal Testing to production. Include who to contact if the build fails or if signing/credentials need to be rotated. Keep it in the repo or in a shared wiki so it's always one link away.

This list is a starting point, not a final rulebook. Add what fits your stack, compliance (e.g. HIPAA, PCI), and team. Use it as a baseline, ship your MVP, then improve each area as you go. If something on your checklist has saved you more than once, share it in the comments or in your own post—tag it so others can find it.

Saad Mehmood — Portfolio

What "Clean Code" Means to Me in a React Codebase

Saad Mehmood — Thu, 12 Feb 2026 18:38:55 +0000

“Clean code” can mean anything. In a React (or React Native) codebase, here’s what I actually aim for—concrete, not vague.

1. One Job Per Component

A component should do one thing: render a list, show a form, display a card. If it’s doing “fetch data + transform + render + handle three different states,” I split it. Smaller components are easier to read, test, and reuse. I extract hooks for logic (data fetching, form state) so the component stays mostly presentational.

2. Names That Describe Purpose

Components: UserCard, OrderSummary, LoginForm—names that say what they are. Functions: formatCurrency, getUserDisplayName, validateEmail—names that say what they do. I avoid Wrapper, Container, or Component1 unless there’s no better name. Good names reduce the need for comments.

3. Fewer Props, Clear Contracts

I keep the prop list short. If a component needs many props, I consider: is it doing too much? Can some props be grouped (e.g. user: { name, avatar })? I use TypeScript so the contract is explicit. Optional props are optional for a reason; I don’t add “just in case” props.

4. No Magic in the Tree

I avoid inline object/array literals and inline functions in JSX when they’re used as props to children. They break referential equality and cause unnecessary re-renders. I use useMemo / useCallback when the value or handler is passed to a memoized child; otherwise I keep them outside the tree or in stable refs. No “it works but I don’t know why” performance.

5. State in the Right Place

I keep state as close as possible to where it’s used. If only one component needs it, it lives there. If two siblings need it, I lift to the parent (or use a small context). I don’t put everything in a global store “for later.” Server state goes in TanStack Query (or similar), not in Redux or Context by default.

6. Boundaries for Side Effects

Data fetching, subscriptions, and other side effects live in useEffect (or in a library like TanStack Query). I don’t fetch in render or mix side effects with pure rendering logic. Cleanup (unsubscribe, abort) goes in the effect’s return. That keeps components predictable and avoids leaks.

7. Consistency Over Personal Taste

I follow the project’s existing patterns: file structure, naming, where state lives, how we handle errors. I don’t introduce a new pattern “because I like it” without team agreement. Consistency makes the codebase navigable for everyone.

Clean code, to me, is: one job per piece, clear names, explicit contracts, minimal magic, state and effects in the right place, and consistency. Boring and repeatable—and that’s the point.

Saad Mehmood — Portfolio

Firestore vs Realtime Database: Which Is Best and Why?

Saad Mehmood — Thu, 05 Feb 2026 06:07:26 +0000

Firebase offers two databases: Realtime Database (the original JSON tree) and Cloud Firestore (the newer document database). Both sync in real time and work offline, but they’re built for different needs. Here’s how they compare and which one I pick—and why.fi

Quick Overview

	Realtime Database	Firestore
Model	Single JSON tree; data nested under paths	Collections + documents; each doc can have subcollections
Queries	Deep path reads; no real “query language”	Rich queries: where, orderBy, limit, compound indexes
Scaling	Single region; scales but with limits on fan-out	Multi-region; designed to scale with automatic sharding
Offline	Full offline with persistence	Full offline with persistence
Pricing	Per GB stored + bandwidth; often cheaper at tiny scale	Per read/write/delete + storage; can get costly with heavy reads
Latency	Very low (single tree, simple reads)	Slightly higher (more flexible but more work per query)

Realtime Database: What It Is and When It Shines

What it is — One big JSON tree. You read and write at paths like /users/uid/profile or /chats/chatId/messages. Data is nested; you listen to a path and get everything under it (or use shallow reads to limit depth). There’s no “query by field” — you structure the tree so that the path is your query (e.g. “messages for this chat” = one path).

Strengths:

Simple — No collections, no indexes. You just read/write paths. Great for small apps and prototypes.
Very low latency — Single tree, direct path access. Good for high-frequency updates (e.g. presence, cursor position, live scores).
Cheap at small scale — If you have little data and moderate traffic, storage + bandwidth pricing can be lower than Firestore’s read/write model.
Tiny SDK — Smaller bundle than Firestore; matters for very constrained environments.

Weaknesses:

No real queries — You can’t “get all users where role = admin” or “messages where createdAt > X.” You either read a path and filter in the client or denormalize heavily and maintain multiple paths. Complex querying gets messy fast.
Scaling and depth — Deep trees and wide “fan-out” (e.g. one write that touches many paths) don’t scale as well. You hit limits and have to flatten or split data.
Structure — Everything is a tree. Relations and many-to-many are awkward; you end up with duplicated data and sync logic.

When I use it: Simple real-time apps (presence, simple chat, live counters), prototypes, or when the data is naturally a tree and query needs are minimal. Also when the team already has a Realtime Database app and migration isn’t worth it.

Firestore: What It Is and When It Shines

What it is — A document database. Data lives in collections (e.g. users, chats); each document has an ID and key-value (and nested) data. You can have subcollections (e.g. chats/chatId/messages). You query with where, orderBy, limit, and compound indexes. Realtime listeners work on collections or query results.

Strengths:

Real queries — “Users where role == 'admin',” “messages where chatId == X orderBy createdAt limit 50.” You model data once and query it many ways. Compound indexes are explicit and predictable.
Scales better — Designed for large apps. Multi-region, automatic scaling. No single-tree bottleneck. Better for many collections and complex access patterns.
Clearer data model — Documents and subcollections map well to “entities” and relations. Less denormalization than Realtime Database for the same flexibility.
Offline — Same strong offline support; queries and listeners work offline with persistence.

Weaknesses:

Pricing can bite — You pay per read/write/delete. Heavy read traffic (e.g. “list all items” on every open) can get expensive if you don’t cache or paginate. You need to think about read volume.
More setup — Indexes, security rules, and data modeling take more thought than “just a path.”
Slightly higher latency — More flexible queries mean a bit more work per request than a single path read. Usually negligible for most apps.

When I use it: Most new Firebase apps. Anything that needs “list by X,” “filter by Y,” pagination, or multiple views over the same data. Apps that will grow in data and query complexity.

Side-by-Side: Key Differences

Data structure — Realtime Database = one tree; Firestore = collections + documents + subcollections. Firestore fits relational-ish and multi-entity models better.

Querying — Realtime Database = path-based (and maybe client-side filter); Firestore = server-side queries with where/orderBy/limit and indexes. Firestore wins for anything beyond “give me this path.”

Scaling — Realtime Database scales but has a single-tree and fan-out limits; Firestore is built for scale and multi-region. For growth, Firestore is the safer bet.

Cost — At tiny scale and low reads, Realtime Database can be cheaper (GB + bandwidth). At higher read/write volume or complex queries, Firestore’s model is easier to reason about and often comparable or better if you design for it (pagination, cache, avoid unnecessary reads).

Offline — Both support offline persistence and sync. No clear winner; both are good.

Which Is Best? My Recommendation

For most apps today: Firestore is the better default.

Reasons:

Querying — Almost every app eventually needs “get items by condition” or “ordered list with pagination.” Firestore does that natively; Realtime Database forces workarounds and denormalization.
Scaling — If the app grows, Firestore scales with you. Realtime Database can hit structural limits and require big refactors.
Data model — Documents and collections match how we think about users, chats, posts, etc. Easier to maintain and onboard others.
Ecosystem and future — Google is investing in Firestore (multi-region, better tooling). Realtime Database is stable but not where new features land first.

When Realtime Database is still the best choice:

Very simple real-time only — Presence, live counters, or a tiny tree with almost no query needs. Simplicity and latency matter more than flexibility.
Strict cost at tiny scale — You have almost no reads/writes and want the smallest bill; Realtime Database’s pricing can be lower.
Existing Realtime Database app — Migration has a cost. If the current app is simple and stable, staying on Realtime Database is fine until you need Firestore’s query and scale.

Summary: Use Firestore for new projects and anything that needs queries or will grow. Use Realtime Database for simple, path-based real-time apps or when you’re already on it and migration isn’t justified. In practice, “which is best” = Firestore for most cases; Realtime Database for a narrow but real set of use cases.

*Saad Mehmood — Portfolio

Why AI Is Important in Coding Today?

Saad Mehmood — Thu, 05 Feb 2026 06:00:01 +0000

AI has moved from research labs into the daily workflow of developers. Here’s why it matters for coding today—and how to use it without losing the skills that make you a strong engineer.

1. Speed Without Sacrificing Quality

Faster first drafts — Boilerplate, config, tests, and repetitive code can be generated in seconds. You spend less time on the predictable parts and more on logic, design, and edge cases.

Consistent patterns — AI can follow the patterns you specify (e.g. “use our API handler wrapper,” “follow our component structure”). That keeps style and structure consistent across the codebase and reduces review back-and-forth.

Quick exploration — When you need to try a new library, language, or API, AI can outline examples and explain options. You get a head start instead of starting from empty files and docs.

Speed here means less time on mechanical work, not skipping thinking. You still decide what to build, how it fits the system, and whether the output is correct.

2. Learning and Unblocking

Explain and explore — “How does X work?” or “Why did we do it this way?” can be answered in context. AI can summarize docs, compare approaches, and clarify concepts so you learn while you code.

Unblock faster — Stuck on an error, a vague requirement, or an unfamiliar codebase? Describing the problem and pasting relevant code often leads to concrete suggestions. You still validate and adapt the answer, but you spend less time stuck.

Fill knowledge gaps — You don’t have to be an expert in every language, framework, or domain. AI can help with syntax, idioms, and “how do people usually do X?” so you can work outside your comfort zone with more confidence.

Learning stays with you; AI is a tool to get there faster and to keep growing.

3. Code Quality and Consistency

Catch obvious issues — AI can suggest fixes for common bugs, missing null checks, or style issues. It’s another pass over the code, not a replacement for tests and review.

Refactors and improvements — “Make this more readable,” “split this function,” or “add error handling” can be applied across a file or module. You stay in control of the design; AI helps with the edits.

Documentation — Comments, READMEs, and docstrings can be drafted from the code. That keeps docs closer to what the code actually does and reduces the “I’ll document it later” gap.

Quality still depends on your judgment: what to change, what to ship, and what “good” means for your project.

4. Handling Repetition and Scale

Repetitive tasks — Similar components, API clients, or test cases can be generated from a clear description or example. You tweak and integrate instead of typing the same structure again and again.

Large codebases — “Where is X used?” or “What calls this function?” can be answered with semantic search and summarization. AI helps you navigate and reason about size and complexity.

Maintenance — Upgrading deps, fixing deprecations, or applying a pattern across many files is tedious. AI can propose changes at scale; you review and apply what’s correct.

Repetition and scale are where AI can save the most time, as long as you verify the results.

5. Collaboration and Communication

Specs and tickets — User stories, acceptance criteria, and technical notes can be drafted from a short brief. You refine instead of starting from a blank page.

Reviews and feedback — AI can suggest wording for PR comments or docs so feedback is clear and consistent. The decisions remain human; the phrasing can be improved.

Onboarding — New team members (or your future self) can get summaries of modules, architecture, and “how we do X here.” That speeds up onboarding and keeps tribal knowledge from living only in people’s heads.

AI supports how teams communicate and collaborate; it doesn’t replace the need for clear thinking and discussion.

6. Staying Current in a Fast-Moving Ecosystem

New tools every week — Frameworks, APIs, and best practices change constantly. AI can summarize what’s new, compare “old way vs new way,” and help you adopt upgrades or new libraries without reading every changelog and doc from scratch.

Lower barrier to try new things — Want to try a new language, a new framework, or a new API? AI can outline setup, common patterns, and gotchas so you can experiment quickly instead of spending days in docs before writing a single line.

Keep skills relevant — The stack you learned five years ago isn’t the only one that matters. AI helps you bridge gaps so you can contribute to new parts of the codebase or new projects without feeling like you’re starting from zero.

Staying current is part of the job; AI makes it less overwhelming.

7. Less Context Switching, More Flow

Answers in the editor — You can ask “how do I do X in this library?” or “why is this failing?” without leaving your IDE. No more tab-hopping to docs, Stack Overflow, or internal wikis in the middle of a task.

Suggestions in context — AI sees the file you’re in, the error you hit, or the code you selected. Suggestions are tailored to your project and your current focus, so you spend less time re-explaining and more time coding.

Stay in flow — Interruptions and context switches cost time and focus. When answers and drafts are a keystroke away, you keep momentum instead of losing it every time you need to look something up.

Flow matters for quality and speed; AI helps you stay in it.

8. Testing, Edge Cases, and “What Could Go Wrong?”

Generate test cases — Describe the behavior you want, and AI can suggest unit tests, integration tests, or edge cases you might have missed. You still decide what to test and what “good enough” is; AI helps you get there faster.

Mock data and fixtures — Realistic test data and mocks can be generated from a schema or a short description. Less time building fixtures by hand, more time writing meaningful tests.

Challenge your assumptions — “What could go wrong here?” or “What edge cases should I handle?” can surface failure modes and boundary conditions. You get a second pair of eyes (of a kind) before code goes to production.

Better coverage and fewer “how did we miss that?” moments—without writing every test from scratch.

9. Security and Best Practices

Secure-by-default suggestions — AI can suggest parameterized queries instead of string concatenation, safe handling of user input, or proper use of auth and secrets. It’s a nudge toward safer patterns when you’re moving fast.

Common vulnerabilities — It can flag obvious issues (e.g. hardcoded secrets, unsafe deserialization, or missing validation) and point you to fixes. Not a replacement for security review, but an extra pass.

Best practices in context — “How should I structure this?” or “What’s the recommended way to do X in this framework?” keeps you aligned with community and team standards without memorizing every guideline.

Security and consistency improve when good patterns are suggested where you code, not only in a separate review.

AI Isn’t Taking Jobs—It’s Changing Them

A common worry is that AI will replace developers. In practice, it’s not taking jobs; it’s changing what the job looks like.

AI needs a human in the loop — It can suggest code, explain concepts, and draft docs, but it can’t own the product. Someone still has to decide what to build, whether the output is correct, how it fits the architecture, and when to ship. AI doesn’t sit in standups, talk to users, or take responsibility for production. Those roles don’t go away.

Demand for software is growing — More products, more integrations, and more automation mean more code and more systems to build and maintain. AI helps each developer do more; it doesn’t remove the need for developers. Teams that use AI well can ship more and take on more work—they don’t typically shrink the team to “one person + AI.”

The job shifts, it doesn’t disappear — Less time on boilerplate and repetitive tasks means more time on design, debugging, collaboration, and the messy problems that still require human judgment. The skills that matter—understanding requirements, making tradeoffs, reading and refactoring code, and working with others—stay central. AI is a tool that makes those skills more productive.

History repeats — Compilers, IDEs, and Google didn’t kill programming; they made it scale. AI is another lever. Developers who learn to use it well become more valuable, not obsolete. The ones at risk are those who refuse to adapt—not because AI “takes” the job, but because others who use AI will outperform them.

So: AI isn’t taking your job. It’s changing the job. Embrace it as a tool, keep building your judgment and skills, and you stay ahead.

How to Use AI Without Losing Your Edge

You’re still the architect — You decide what to build, how it fits the system, and what “done” looks like. AI suggests and drafts; you decide.
Verify everything — Test generated code, check facts, and question suggestions. AI can be wrong or outdated. Your job is to catch that.
Use it to learn — When AI writes something you don’t understand, dig in. Ask for explanations, read the docs, and make sure you could do it yourself next time.
Keep core skills — Debugging, design, and reading code are as important as ever. Use AI to go faster, not to avoid learning the fundamentals.

Bottom Line

AI is important in coding today because it makes the mechanical and repetitive parts of the job faster while leaving the creative and judgment-heavy parts to you. Used well, it helps you ship more, learn more, and focus on the work that actually differentiates your product and your skills. The goal isn’t to replace the developer—it’s to make the developer more effective.

Saad Mehmood — Portfolio

# Expo vs Bare React Native

Saad Mehmood — Fri, 30 Jan 2026 18:20:14 +0000

Expo has evolved from “managed only” to a full toolkit that can still eject to bare when needed. Here’s how I think about Expo vs bare React Native in 2025.

Expo (EAS, managed or custom dev client)

Pros:

EAS Build — Build in the cloud without Xcode/Android Studio on your machine. Signing and provisioning are handled. Great for CI and for devs who don’t want to maintain native toolchains.
EAS Submit — Push builds to TestFlight and Play Internal (or production) from the CLI. Integrates with EAS Build so you can go from commit to store in one pipeline.
Expo SDK — Camera, maps, notifications, updates, and more via a consistent API. Often less native code to write and upgrade.
Over-the-air updates — EAS Update lets you ship JS (and asset) changes without a full store release. Useful for hotfixes and A/B tests.
Documentation and DX — Docs are good, and the CLI (e.g. npx expo start) is smooth. Fast Refresh and dev client make iteration fast.
Custom dev client — You can add native modules and still use EAS Build and most of the Expo tooling. You’re not locked out of native code.

Cons:

Native control — For very custom native behavior or bleeding-edge native APIs, you might need to patch or fork. Usually it’s manageable with config plugins or a custom dev client.
Bundle and runtime — Expo adds some size and abstraction. For most apps it’s fine; for very constrained environments you might care.
Learning curve — If the team has only ever used bare RN, they’ll need to learn EAS and the Expo way of doing things.

When I choose it: For most new React Native apps. EAS Build and Submit alone save a lot of pain. I use a custom dev client when I need native modules that aren’t in the default SDK. I use managed when the app stays within Expo’s supported surface.

Expo prebuild: how native projects are generated

prebuild is the step that creates (or updates) the ios/ and android/ folders from your Expo config. You don’t have to write those projects by hand—Expo generates them from app.json / app.config.js and config plugins.

What it does — Reads your app config and plugin list, then generates a native Xcode and Android project. Config plugins run during prebuild to add permissions, native dependencies, or custom native code (e.g. expo-camera, expo-notifications). So you stay in a config-driven workflow even when you need native code.
When it runs — In EAS Build, prebuild runs by default before each build unless you’ve committed ios/ and android/ and use a profile that skips it. Locally, you run npx expo prebuild when you want to generate or refresh the native projects. Use npx expo prebuild --clean to regenerate from scratch (useful after changing plugins or app config).
Managed vs bare-ish — In a managed workflow you often don’t commit ios/ and android/; EAS Build runs prebuild every time so the native project always matches your config. In a custom dev client or “bare-ish” workflow you might run prebuild once, then commit the native folders and edit them. After that, either keep maintaining those folders or run prebuild again and re-apply your changes (or use config plugins so the changes are reproducible).
Why it matters — prebuild is what lets you add native modules and still use EAS Build and Expo tooling. You’re not stuck choosing between “no native code” and “fully manual native projects.” You get generated native projects that stay in sync with your Expo config and plugins.

Bare React Native

Pros:

Full control — Every native file is yours. You can change anything, add any library, and tune the native project exactly how you want.
No Expo layer — Slightly smaller surface area: no Expo runtime or config plugins. Some teams prefer “just RN + native.”
Existing projects — Plenty of codebases started bare. If you’re maintaining one, staying bare can be simpler than migrating to Expo.

Cons:

Build and signing — You own Xcode/Android Studio, certificates, provisioning, and CI. That’s a real cost in time and frustration.
Updates — You have to upgrade React Native and native deps yourself. Expo abstracts some of that; bare doesn’t.
No EAS Update — You can add a different OTA solution (e.g. CodePush), but it’s not built in like EAS Update.

When I choose it: When the app needs native behavior Expo doesn’t support (or would require heavy patching), when the team already has a bare setup they’re happy with, or when we need to match an existing bare codebase. I don’t go bare “just because”—I go bare when there’s a clear reason.

Summary

New app, standard needs — I start with Expo (managed or custom dev client) and use EAS Build + Submit. I only go bare if we hit a wall.
Heavy native or existing bare — I use or stay with bare when control or existing investment justifies it.
2026 — Expo is production-ready and widely used. The “Expo = can’t use native” idea is outdated. Choose based on your app’s needs and your team’s comfort with native tooling, not on old stereotypes.

Saad Mehmood — Portfolio

Why I Choose React Native Over Flutter for Cross-Platform Mobile Development

Saad Mehmood — Wed, 28 Jan 2026 14:49:11 +0000

React Native and Flutter are both solid choices for building cross-platform mobile apps. Here’s why I reach for React Native more often—and when Flutter might still be the better fit.

One Language and Ecosystem for Web and Mobile

React Native lets you use JavaScript or TypeScript—the same languages most web teams already use. If you or your team build React web apps, you’re already most of the way there: same mental model (components, state, props), same tooling (npm/yarn, ESLint, VS Code), and a lot of shared logic. You can reuse utilities, types, and sometimes even UI code between web and mobile.

Flutter uses Dart, which is a good language but another one to learn and maintain. For teams that are primarily web-focused, React Native reduces context-switching and speeds up onboarding.

Huge Ecosystem and Third-Party Libraries

React Native sits on top of the npm/JavaScript ecosystem. There’s a library or solution for almost everything: auth, analytics, payments, maps, charts, camera, and countless native modules. Expo expands that further with a curated set of modules and a smooth dev experience. Finding answers, examples, and Stack Overflow threads is easy.

Flutter’s pub.dev is growing, but the breadth and depth of the JS ecosystem still give React Native an edge when you need an obscure integration or a quick workaround.

Native Components and “Write Once, Run Anywhere” Feel

React Native uses native UI components under the hood. Your views map to real UIView and View on iOS and Android, so the app looks and feels like a native app—platform conventions, accessibility, and system controls behave as users expect. You can drop down to native code when you need to.

Flutter draws everything with its own engine (Skia), which gives pixel-perfect consistency and great performance, but the look can feel more “Flutter-ish” unless you invest in platform-specific theming. React Native’s approach often gets you closer to native look-and-feel with less effort.

Faster Iteration and Hot Reload

React Native’s Fast Refresh (and legacy hot reload) lets you see UI and state changes almost instantly without a full rebuild. That tight feedback loop matters a lot for layout tweaks, styling, and debugging. Flutter has hot reload too and it’s good; in practice, both are fast. React Native’s iteration speed is one of the reasons it’s so pleasant for UI-heavy work.

One Team for Web and Mobile

If you’re a full-stack or frontend web developer, adding mobile with React Native is a natural step. You don’t need a separate “Flutter/Dart” specialist for the mobile app—the same people who build your React or Next.js front end can own the React Native app. That simplifies hiring, code reviews, and shared standards.

When Flutter Might Be the Better Choice

React Native isn’t always the answer. Flutter can be better when:

You want very custom, highly branded UI and are okay with owning the whole visual layer (e.g. games, design-heavy apps).
You need strong consistency across platforms with a single design system and little platform-specific UI.
Your team already knows Dart or is willing to invest in it.
You’re building for desktop (Windows, macOS, Linux) or embedded where Flutter’s story is mature.

Bottom Line

I choose React Native when I want to ship cross-platform mobile apps with the same language and ecosystem I use for the web, leverage the npm ecosystem, and keep one mental model for web and mobile. For many product teams and full-stack developers, that makes React Native the more practical default. Flutter is powerful and has real advantages—but for “web devs doing mobile,” React Native often wins.

What’s your go-to for cross-platform mobile—React Native, Flutter, or something else? Share in the comments.

Saad Mehmood — Portfolio

Why Understanding Beats Memorizing in Programming

Saad Mehmood — Tue, 27 Jan 2026 20:30:36 +0000

You don’t need to memorize every syntax or API. You need to understand how things work. Here’s why that shift matters—and how to focus on understanding instead of rote recall.

The Memorization Trap

A lot of us were taught to learn by memorizing: syntax, built-in methods, framework APIs, “patterns” from tutorials. It feels productive—we can recite Array.prototype methods or write a for-loop without looking. But when the problem changes slightly, or we switch languages, or we’re asked “why did you do it that way?” we freeze. Memorization gives the illusion of knowledge. It doesn’t give you the ability to adapt.

Programming is not a spelling test. The goal isn’t to recall a snippet from memory—it’s to solve a problem by reasoning about data, flow, and structure. Understanding is what makes that possible.

Why Understanding Outweighs Memorizing

1. You Can Recover What You Forgot

If you understand how loops work (repeat this block; condition; iteration), you can reconstruct a for, while, or forEach in any language. You might look up the exact syntax, but you’re not lost. If you only memorized one loop form, a different language or style leaves you stuck. Understanding is portable; memorization is brittle.

2. You Can Debug and Modify Confidently

Bugs happen when reality doesn’t match what we expect. To fix them, you have to form a mental model (“this variable holds X at this point”), compare it to what the code actually does, and find the mismatch. That’s reasoning—it depends on understanding, not on remembering a solution. Same for changing code: if you understand the flow and the data, you can modify it safely. If you memorized a block, every change feels like guesswork.

3. You Can Learn New Things Faster

New frameworks, libraries, and languages keep showing up. No one can memorize them all. But if you understand core ideas—state, side effects, composition, data flow—you recognize them everywhere. New tech becomes “same ideas, different syntax.” Understanding compresses learning; memorization doesn’t scale.

4. You Can Explain and Collaborate

In reviews, pair programming, and interviews, people ask “why?” If you understand your code, you can explain the tradeoffs and the reasoning. If you memorized a pattern, the best you can say is “I saw it in a tutorial.” Understanding makes you a better teammate and a stronger candidate.

5. You Retain It Longer

Things you understand stick. You’ve connected them to principles and to other ideas. Things you only memorized fade when you don’t use them daily. Investing in understanding pays off over years; cramming for a quick win doesn’t.

6. You Don’t Fear Switching Languages

If you’ve only memorized one language or framework, the idea of changing stacks can feel scary—as if you’ll have to start from zero and memorize everything again. When you understand concepts (loops, functions, data structures, APIs, state), switching languages is mainly new syntax and idioms. The mental model transfers. Memorizers stay locked in; understanders adapt. Reducing that fear is one of the biggest rewards of learning by understanding.

What “Understanding” Means in Practice

It doesn’t mean “no documentation.” It means that for the code you write or use, you can:

Explain what it does and why (in plain language).
Trace it: given this input, what happens step by step?
Relate it to a bigger idea (e.g. “this is a reduce because we’re turning a list into one value”).
Change it: you know what to tweak and what might break.

You’re allowed to look up method names and signatures. The goal isn’t to hold everything in your head—it’s to hold the model of how things work.

How to Prioritize Understanding

Learn concepts, then syntax

Before memorizing “how to write a loop in Python,” get clear on what a loop is (repeat until condition) and when you’d use it. Concept first; syntax follows and is easy to look up.

Build a mental model before writing

For each small task, ask: “What data do I have? What do I need? What steps get me there?” Sketch in comments or pseudocode. Then translate to real code. That habit forces understanding instead of copy-paste.

Break and fix on purpose

Change one thing—a condition, a variable name, the order of operations—and run the code. See what breaks. Then revert and try another change. You’re not just running code; you’re testing your mental model.

Explain it to someone (or a rubber duck)

If you can explain a function or a block in simple language, you understand it. If you can’t, you’ve found the gap. Teaching is one of the best ways to deepen understanding.

Use reference materials without guilt

Docs, Google, and AI are for lookup—syntax, APIs, examples. Use them. The skill is not “remembering everything,” but “knowing what to look for and how to apply it.” That comes from understanding the concept.

The Bottom Line

Memorization has a small place: things you use every day (e.g. basic Git commands, your editor shortcuts) become muscle memory. But the core of programming is thinking: breaking down problems, modeling data and flow, and choosing approaches. That’s driven by understanding.

So when you learn something new, ask yourself: “Do I understand why this works, or do I just remember what to type?” If it’s the latter, pause and close the gap. Your future self—debugging at 2 a.m. or learning a new stack—will thank you.

If this resonates, drop a comment with how you switch from memorizing to understanding when learning something new. Happy coding.

Saad Mehmood — Portfolio

Why Junior Developers Must Understand the Code—Not Just AI and Vibe Coding

Saad Mehmood — Tue, 27 Jan 2026 13:31:42 +0000

I work with new developers often, and one pattern keeps showing up: heavy reliance on AI tools and copy-pasting from tutorials or the web without really understanding what the code does. This isn’t a rant about AI or “the way things were.” It’s about what happens when you skip the “why” and only do the “what”—and what to do instead.

The Problem I’m Seeing

More and more juniors:

Get a task, paste a solution from ChatGPT/Claude/Cursor, and move on.
Follow a tutorial step-by-step, get something working, but can’t explain the code or change it later.
Fix bugs by trying the next AI suggestion or Stack Overflow answer until something works, without understanding why.

The result? Code that “works” until it doesn’t. When it breaks—in prod, in a review, or in an interview—they’re stuck because they never built a mental model of what’s actually happening.

Why “It Works” Isn’t Enough

1. You Can’t Debug What You Don’t Understand

If you don’t know what a piece of code is doing, you can’t reason about why it failed. Debugging is basically asking: “Given what this code is supposed to do, where did reality differ?” If you never knew what it was supposed to do, you’re just guessing.

2. Small Changes Become Scary

Someone asks: “Can we change this so it also does X?” If you pasted the block from an AI or a tutorial and never understood it, every change feels risky. You either avoid it or paste another block and hope it fits. Understanding turns “magic code” into something you can modify confidently.

3. Interviews and Reviews Expose the Gap

In interviews and code reviews, people ask “why did you do it this way?” or “what does this line do?” If the honest answer is “the AI wrote it” or “the tutorial said so,” that’s a red flag. Knowing the flow, the types, and the tradeoffs is what separates a junior who grows from one who stays stuck.

4. You Don’t Build Real Skills

Copy-paste and “AI did it” don’t create lasting skills. The skill is in reading code, tracing execution, and making deliberate decisions. Without that, years of “shipping” can still leave you unable to design or debug on your own.

What “Understanding the Code” Actually Means

It doesn’t mean memorizing everything. It means for the code you write or change, you can:

Explain what it does in plain language (data in → steps → data out).
Trace it: given this input, what happens line by line (or step by step)?
Justify choices: why this function, this structure, this library?
Modify it safely: where to change things and what might break.

You don’t need to know every API by heart. You need to know how to read the code and the docs and reason about cause and effect.

How to Use AI and the Web Without Falling Into the Trap

Use AI as a Tutor, Not a Substitute for Thinking

Ask “explain this code line by line” or “what’s the tradeoff between approach A and B?”
After you get a solution, step through it yourself. Comment each part in your own words. If you can’t, slow down and learn that part before moving on.
Use AI to generate tests or examples, then run them and change them so you see how behavior changes. That forces understanding.

Use Tutorials and Web Answers as Starting Points

After copying a snippet, break it: remove a line, change a value. See what breaks and what doesn’t. That teaches you what that part is responsible for.
Before pasting, try to write a one-sentence summary of what the solution does. If you can’t, treat it as something to learn, not just use.

Build a “Understand First, Then Implement” Habit

For each feature or bug: spend a few minutes stating the goal and the constraints in your own words.
Then see if you can sketch the approach (even in pseudocode or comments) before opening AI or Google. You don’t have to get it right—you have to think first.
Use AI and the web to fill in details, correct your sketch, or show best practices—not to replace that thinking.

Learning Principles That Help

Fundamentals before frameworks

Variables, flow, functions, data structures, and basic async. If you understand these, any framework or tool becomes “syntax and patterns” on top of something you already get.
Read and trace before you write

Open an existing file and trace one user action or one request from top to bottom. Write a short note: “When X happens, the code does A, then B, then C.” Do this often.
Break things on purpose

Change one thing, run the app, see what happens. Then revert and try another change. This builds a causal model of the codebase.
Explain to someone (or a rubber duck)

If you can explain a function or a flow in simple language, you understand it. If you can’t, you’ve found the exact spot to study.
Ship small, understandable pieces

Prefer a simple loop you understand over a “clever” one-liner you don’t. Readable and correct beats short and mysterious.

A Message to Juniors

Nobody expects you to know everything. Everyone uses AI and the web. The difference is whether you use them to avoid understanding or to speed up understanding.

When you paste code, pause. Ask yourself: “In 30 minutes, could I explain this to another developer?” If not, block that 30 minutes and make sure you can. That habit is what turns you from someone who depends on AI and webcoding into someone who can debug, redesign, and grow—with or without tools.

A Note to Seniors and Teams

If you’re mentoring or hiring: assume good intent. Juniors aren’t “cheating” by using AI; they’re trying to be productive. The fix isn’t to ban tools—it’s to set the bar clearly: “We value code you can explain and modify.” Do code reviews that ask “what does this do?” and “why this approach?” Pair on debugging and walk through the execution flow together. Model “I don’t know—let me read the code and find out.” That’s how you help new developers build the habit of understanding, not just delivering.

If this resonates—especially if you’ve been on either side of this—drop a comment or share how you balance using AI with actually understanding the code. Happy coding, and here’s to writing code we can explain.

Saad Mehmood — Portfolio