DEV Community: Saad Mehmood

Next.js vs React: Why Next.js Is the Better Choice for Most Web Projects

Saad Mehmood — Thu, 21 May 2026 12:58:13 +0000

If you search "Next.js vs React," you'll see a lot of articles that treat them like two competing frameworks. That's the wrong starting point.

Next.js is built on React. You're not choosing React or Next.js. You're choosing between:

a plain React project (Vite, Create React App, or a custom SPA setup), and
a React project with Next.js as the framework on top.

After 8+ years building web apps — from MVPs to production platforms — I default to Next.js for almost every serious web project. Not because React is bad. React is excellent. But for real products, Next.js gives you a full stack of decisions already made — and those decisions are usually the right ones.

Here's why.

1. SEO and First Load Are Built In, Not Bolted On

A plain React SPA typically ships a mostly empty HTML shell. The browser downloads JavaScript, React mounts, data is fetched, and then the user sees content.

That works for dashboards behind login. It is painful for:

portfolios
landing pages
blogs
marketing sites
anything that needs Google, LinkedIn previews, or fast first paint

Next.js solves this at the framework level with:

Server Components (App Router) — render on the server by default
Static generation (SSG) — pre-build pages at deploy time
Server-side rendering (SSR) — render per request when needed
Streaming — send HTML in chunks while slower parts load

With a plain React app, you can add SSR — but you're assembling tools yourself (custom Node server, hydration setup, routing, caching). With Next.js, it's the default path.

Real impact: better Core Web Vitals, better crawlability, better social sharing previews — without a separate backend just to render HTML.

2. Routing Is a Feature, Not a Dependency You Wire Up

In a plain React project, routing usually means:

install react-router
define routes manually
handle layouts yourself
figure out code splitting per route
add loading and error states yourself

In Next.js, the file system is the router:

app/
  page.tsx          → /
  about/page.tsx    → /about
  blog/page.tsx     → /blog
  layout.tsx        → shared layout
  loading.tsx       → loading UI
  not-found.tsx     → 404 page

Nested layouts, route groups, dynamic segments, and error boundaries are first-class. You spend less time on plumbing and more time on product.

I've shipped multi-page sites (portfolio, blog, project pages) where adding a new route is literally creating a folder and a page.tsx. That velocity matters on client work.

3. Full-Stack in One Repo (Without a Separate API Project)

Plain React is frontend-only. Need an API? You spin up Express, Nest.js, or Firebase Functions in another repo — then deal with CORS, auth, deployment coordination, and env var duplication.

Next.js gives you:

Route Handlers (app/api/.../route.ts) — REST endpoints
Server Actions — mutations from the client without writing a separate API layer
Server-side data fetching — call your DB or third-party APIs directly in Server Components

For many apps — contact forms, CMS fetches, auth callbacks, webhooks, internal tools — you don't need a standalone backend on day one.

Example use cases I've used Next.js API routes for:

blog post fetching
form submissions
webhook receivers
server-side token exchange (keeping secrets off the client)

One repo. One deploy. Less context switching.

4. Performance Optimizations You'd Otherwise Skip

Next.js ships with optimizations that teams often postpone in plain React projects because "we'll add it later" (and never do):

Feature	Plain React	Next.js
Automatic code splitting	Manual setup	Built in per route
Image optimization	You pick a library	`<Image />` component
Font optimization	Manual	`next/font`
Script loading strategy	Manual	`<Script />` component
Bundle analysis	Extra tooling	`@next/bundle-analyzer`

The <Image /> component alone is worth it on content-heavy sites. Lazy loading, responsive sizes, modern formats (WebP/AVIF), and layout shift prevention — handled.

On a portfolio or product site with screenshots and hero images, this is a measurable win without extra libraries.

5. Better Developer Experience for Production Apps

Things that feel small in a demo but matter in production:

Environment variables — NEXT_PUBLIC_ vs server-only vars are clearly separated
Middleware — auth checks, redirects, geo routing at the edge
Built-in metadata API — SEO tags per page without react-helmet
Incremental Static Regeneration (ISR) — update static pages without full rebuilds
Deployment story — Vercel is first-class, but Next.js also runs on Netlify, AWS, Docker, etc.

When I build client projects, I need predictable structure. Next.js gives every page the same conventions: where data lives, where loading states go, where errors go. New developers on the project ramp up faster.

6. The App Router Changed the Game (2024–2026)

If you looked at Next.js years ago and thought "it's just SSR for React," look again.

The App Router (now the default) gives you:

React Server Components
Streaming and Suspense boundaries
Colocated loading/error UI
Server Actions for forms and mutations
Partial Prerendering (where supported)

This is not "React with extra steps." It's a different — and better — default for web apps that need both interactivity and performance.

I use "use client" only where I need hooks, browser APIs, or heavy interactivity. Everything else stays on the server. Less JavaScript to the browser. Faster pages. Simpler mental model once you learn it.

7. Plain React Still Has a Place (Being Honest)

Next.js is not magic. I still reach for plain React (usually Vite) when:

the app is a logged-in dashboard with zero SEO needs
it's an embedded widget inside another site
the team already has a separate backend and wants a thin SPA frontend
the scope is a small internal tool that will never be public-facing

But even then, I ask: will this ever need SEO, public pages, or server-side data? If yes, I start with Next.js anyway. Migrating from SPA to SSR later is expensive.

Side-by-Side: What You Get on Day One

Plain React (Vite/CRA):

✅ Fast dev server
✅ Full control
❌ No SSR/SSG out of the box
❌ No file-based routing
❌ No API layer
❌ No image/font optimization
❌ SEO requires extra work

Next.js:

✅ Everything React gives you
✅ SSR, SSG, ISR, streaming
✅ File-based routing + layouts
✅ API routes + Server Actions
✅ Image, font, script optimization
✅ Metadata and SEO built in
✅ Production conventions from day one

My Default Decision Framework

When a new web project comes in, I ask:

Does this need to rank on Google or look good when shared? → Next.js
Will we need server-side logic (forms, auth, webhooks)? → Next.js
Is this a multi-page product site? → Next.js
Is this a private admin panel with no public pages? → Plain React is fine

For me, that means Next.js wins roughly 80–90% of the time.

Final Take

React gives you the UI layer. Next.js gives you the product layer — routing, rendering strategy, API, optimization, and deployment patterns that every real web app eventually needs.

Starting with plain React and adding those pieces one by one works. I've done it. But it's slower, easier to get wrong, and you end up rebuilding toward what Next.js already provides.

If you're starting a new web project in 2026 and you're not sure which to pick: use Next.js with the App Router. You'll move faster, ship better-performing pages, and spend your time on features — not infrastructure.

Saad Mehmood — Portfolio | Dev.to

Mentoring Junior Developers: What Actually Works

Saad Mehmood — Thu, 21 May 2026 12:33:50 +0000

Mentoring juniors has taught me as much as it’s taught them. Here’s what actually helps—and what doesn’t.

1. Explain the “Why,” Not Just the “How”

“We do it this way because…” sticks better than “just do it like this.” When you share context (e.g. “we use this pattern so we can test without the API”), they start to generalize and make better decisions on their own. One sentence of why can save a lot of repeated corrections.

2. Code Review as Teaching

PR feedback is a chance to teach. Instead of only “change this,” add “because…” or “an alternative is X, which is better when Y.” Point them to a doc or example when you have one. Over time, they’ll anticipate the same points and need fewer comments.

3. Pair When It’s Sticky

When someone’s stuck for a while, pair for 30–60 minutes. Share screen, talk through the problem, and debug together. You unblock them and see where they get confused—useful for docs or future onboarding. Don’t take over; guide so they drive.

4. Give Them Ownership of a Small Area

Assign a small feature, module, or bug area they own. They get to design, implement, and maintain it. They’ll ask questions and make mistakes—that’s how they learn. You stay available for review and unblocking, but they lead.

5. Normalize “I Don’t Know”

Make it clear that nobody knows everything. Saying “I’m not sure, let’s look it up” or “good question, I’ll find out” models that learning is ongoing. That reduces the pressure to pretend they know and encourages asking questions.

6. Set Clear Expectations

Spell out what “good” looks like: “We expect PRs to have tests for new logic,” “we comment complex bits,” “we update the README when we change setup.” When expectations are clear, they can self-check and improve without guessing.

7. Don’t Fix Everything Yourself

If you always jump in and fix their code, they don’t learn. Let them fix their bugs (with hints if needed). Step in when it’s blocking the team or when they’re truly stuck, but default to “what have you tried? what do you think we should do next?”

8. Check In Regularly

Short, regular check-ins (“how’s the task? any blockers?”) beat long, rare meetings. They get help when they need it, and you notice when they’re stuck or when scope is unclear.

Mentoring well takes time, but it pays off: the team gets stronger, and you get a clearer picture of how your systems and docs work for someone new. The goal isn’t to create clones of you—it’s to help them think and ship with confidence.

Saad Mehmood — Portfolio

What I Wish I'd Known as a Junior Full-Stack Developer

Saad Mehmood — Thu, 21 May 2026 12:29:53 +0000

Looking back at my first years as a full-stack developer, here’s what would have saved me time, stress, and a few mistakes.

1. You Don’t Have to Know Everything

It’s normal to feel overwhelmed. Senior devs don’t know every framework or language—they know how to find answers, read docs, and debug. Focus on one stack first, get good at it, then expand. “I don’t know, but I’ll find out” is a valid and professional answer.

2. Ask Questions Early

Asking “how does this work?” or “what’s the expected behavior?” early is better than guessing and building the wrong thing. Write down answers so you don’t ask the same thing twice. Good teams expect questions; they’d rather clarify than rework.

3. Estimates Are Hard—That’s Okay

Estimates will be wrong at first. Break tasks into small pieces (a few hours each), add buffer for unknowns, and say “I’ll need to spike this before I can give a number” when it’s genuinely unclear. Updating the team when you learn something new is part of the job.

4. Code Review Feedback Is About the Code, Not You

Critique on your PR is about the change, not your worth. Use it to learn patterns and constraints. Ask “what would you do instead?” when you don’t understand. Over time you’ll internalize the team’s style and get fewer comments.

5. Tests and Documentation Pay Off Later

Writing a test or a short doc feels slow until something breaks or someone (including you) forgets how it works. Even a few tests for critical paths and a README that explains how to run the app will save hours later. Start small and add more as you go.

6. Production Is Different From Local

Things that work on your machine can fail in production: env vars, timeouts, scale, caching. Learn how the app is deployed, where logs go, and how to debug production issues (with care). That skill is as important as writing features.

7. Communication Is Part of the Job

Updates, clear messages, and “I’m blocked on X” matter as much as code. A short message or standup update keeps everyone aligned. Don’t disappear for days on a hard problem without saying so.

8. It’s Okay to Rest

Burnout doesn’t help you or the project. Take breaks, protect focus time, and don’t feel guilty for not coding 24/7. Sustainable pace beats hero mode.

If you’re early in your career: you’re not supposed to have it all figured out. Learn in public, ask questions, and get a little better every week. That’s enough.

Saad Mehmood — Portfolio

PostgreSQL vs MongoDB: When I Pick Which for the Backend

Saad Mehmood — Thu, 09 Apr 2026 14:43:08 +0000

PostgreSQL and MongoDB are both capable. The choice usually comes down to data shape, query patterns, team experience, and how much you care about schema and relations. Here’s how I decide.

What Each Gives You

PostgreSQL — Relational model: tables, rows, foreign keys, ACID transactions, and SQL. Strong for structured data, joins, and reporting. Schema is explicit (migrations); you get constraints, indexes, and a mature ecosystem (PostGIS, extensions). Fits when your domain has clear entities and relationships.

MongoDB — Document model: collections and JSON-like documents. Flexible schema; you can evolve documents over time without formal migrations. Good for nested, variable-shaped data (e.g. profiles with optional fields, event payloads). Denormalization is common; you design documents for how you read them. Horizontal scaling and sharding are first-class.

When I Choose PostgreSQL

Structured domain with clear relations — Users, orders, products, roles, permissions. When the data is naturally tabular and you need joins (e.g. “orders with customer and line items”), PostgreSQL is a natural fit. Normalized schema reduces duplication and keeps consistency.
Transactions and consistency — When a single operation must update several rows or tables atomically (e.g. debit one account, credit another), relational DBs and transactions are what you want. PostgreSQL’s transaction model is well understood and robust.
Reporting and analytics — SQL is built for aggregations, filters, and reporting. When the product or stakeholders need “list X by Y, sum Z, group by W,” PostgreSQL (and tools that speak SQL) make this straightforward.
Team knows SQL and relational design — Many backends and agencies are comfortable with tables, migrations, and ORMs (Prisma, TypeORM, etc.). PostgreSQL fits that skillset and has great tooling (Supabase, Neon, etc.).
Nest.js or type-first backends — Nest.js and TypeScript pair well with Prisma/TypeORM and PostgreSQL. You get types from schema, migrations, and a clear data model. I default to PostgreSQL for new Nest.js APIs unless the data is clearly document-shaped.

When I Choose MongoDB

Document-shaped or variable structure — Content with optional fields, user-generated forms, or events where each document can have different attributes. When the schema varies by document or changes often, MongoDB’s flexibility can reduce migration churn.
Nested data read as a unit — When you often load “one thing and everything inside it” (e.g. a project with tasks and comments embedded or in sub-docs), documents can match that read pattern. You avoid joins at the cost of some duplication and careful design to avoid huge documents.
Team prefers document APIs — Some teams are more productive with documents and aggregation pipelines than with SQL. When that’s the case and the data fits, MongoDB is a good fit.
Already in the stack — If the project or client already uses MongoDB and the data is working, we don’t switch to Postgres without a strong reason (e.g. need for complex joins or reporting that’s painful in Mongo).

The “Hybrid” Option

Sometimes we use both: PostgreSQL for core transactional data (users, billing, orders) and MongoDB (or another store) for logs, events, or flexible content. Not every app needs that—but when one part of the system is clearly relational and another is clearly document/event-based, splitting can make sense.

What I Don’t Do

Don’t pick MongoDB to avoid schema — You still need to think about indexes, document shape, and how you’ll query. “Schema-less” doesn’t mean “no design.” Bad document design leads to slow queries and messy code.
Don’t pick PostgreSQL only because “relational is correct” — For highly variable or nested data that’s always read as a whole, documents can be simpler. Choose by data shape and access patterns, not ideology.
Don’t migrate without a clear problem — If the current database is working, we don’t switch to the other just to try it. We switch when we hit real limits (e.g. reporting in Mongo is painful, or we need strict relations and transactions in a doc store).

In short: I default to PostgreSQL for most backends—structured data, relations, transactions, and reporting. I choose MongoDB when the data is document-shaped, variable, or read as a unit, and when the team and stack align with it. Both are production-ready; pick by domain shape, query patterns, and team.

Saad Mehmood — Portfolio

State Management in 2026: Redux vs Context vs TanStack Query

Saad Mehmood — Thu, 09 Apr 2026 10:01:04 +0000

State management in React (and React Native) is clearer than ever in 2026. Here’s how I use Redux, Context, and TanStack Query now, and when I pick each.

TanStack Query — Server State First

Use for: Anything that comes from the server: API data, lists, details, pagination, and background refetching.

TanStack Query handles loading, error, caching, refetching, and invalidation. I keep server data in the query cache and avoid duplicating it in Redux or Context unless there is a strong product reason (for example, special offline behavior).

const { data, isLoading, error } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => fetchUser(userId),
});

When I use it in 2026: For nearly all async/server data. It reduces boilerplate, keeps fetching logic consistent, and scales well in both React and React Native.

Context — Global UI and App Config

Use for: Theme, locale, auth session reference, feature flags, and dependency providers.

Context is best for small, stable, read-heavy global values. Keep provider values minimal and memoized so you avoid unnecessary tree-wide re-renders.

When I use it in 2026: When state is simple and widely shared. If updates become frequent or logic gets complex, I move to a dedicated store.

Redux Toolkit — Complex Client State

Use for: Complex client state: multi-step flows, editor-like UIs, undo/redo, persistence, and strict state transitions.

Redux Toolkit keeps Redux practical with slices and solid conventions. I use it when:

The app has a lot of interdependent client state (wizards, dashboards, editors).
I need deterministic flows and explicit actions for debugging.
I need persistence/rehydration and predictable transitions across screens.
The team is already comfortable with Redux and the project size justifies it.

When I avoid it: For simple apps or when most data is server-driven. In those cases, TanStack Query + Context + local state is usually enough.

Quick 2026 Decision Rule

Server state (API-backed) -> TanStack Query
Global app config (theme/locale/session ref) -> Context
Complex client workflows (wizards/editors/undo) -> Redux Toolkit
Component-only UI state (modal open/input value) -> useState

How They Coexist in Real Projects

TanStack Query for server/cache state.
Context for app-wide configuration and providers.
Redux Toolkit only where client state is complex enough to justify it.
useState for local UI concerns.

I avoid “one tool for everything.” In 2026, the cleanest setups separate state by purpose: server data in query cache, shared config in Context, and complex client workflows in a store. That split keeps code easier to debug and faster to scale.

Saad Mehmood — Portfolio

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