DEV Community: Md. Mehedi Hasan

The 7 Decisions That Quietly Decide Whether Your App Survives

Md. Mehedi Hasan — Mon, 20 Jul 2026 20:30:13 +0000

Your app doesn't crash because of bad code. It crashes because of the decisions you never made.

Where does your data actually live? What happens to your bill when you go from 10 users to 10,000? Who's responsible when something breaks at midnight? Most builders find out the hard way — you don't have to. Here's the 7-question checklist to run before you write your first line of code.

Before you write a single line of code, you make choices you'll be living with for years. Here's how to make them on purpose instead of by accident — explained with a real app.

Imagine two friends, Alex and Sam, decide to build a note-taking app together — think a simple version of Notion. They're excited. They open their laptops and start coding the login page that same night.

Six months later, Alex is up at 2 AM because the database is down and nobody knows how to restore it. Sam just found out a client in Germany can't legally use the app because user data is stored in a country with no privacy agreement. Neither of these problems was a coding bug. They were architecture problems — decisions that should've been made before the first line of code, not discovered in a panic afterward.

This is what "architecture" really means: not the fancy diagrams, but the small set of decisions that are expensive to undo later. Let's walk through seven of them, using Alex and Sam's note-taking app as our running example.

1. Where Should Your Data Be Stored?

Every app needs a home for its data — user accounts, notes, files, settings. The question is: where, physically and logically, does that home sit?

Alex and Sam had three real options:

A managed cloud database (like Amazon RDS or Supabase) — someone else runs the servers, they just use it.
Their own server — full control, but they have to maintain it themselves.
A hybrid — some data in the cloud, some cached locally for speed (like notes stored on your phone so the app works offline).

They picked a managed cloud database. Why? Because neither of them had ever managed a production database before, and a managed service handles the scary parts — patching, scaling, security updates — automatically.

The beginner lesson: where your data lives determines your speed (how fast users can access it), your risk (who's responsible if it leaks), and how much of your time goes into "keeping the lights on" versus building features.

2. How Will Your Expenses Scale Over Time?

Here's a trap almost every new builder falls into: they check the price today and ignore the price at 100,000 users.

Alex and Sam started with a "free tier" database that costs nothing when you have 10 users. But when they modeled it out, they found the app's cost curve was not a straight line — image storage costs jumped sharply once they crossed a certain number of files, because their chosen provider charged much more per gigabyte after the free allowance.

The beginner lesson: ask "what does this cost at 10 users, 10,000 users, and 1,000,000 users?" before you commit. A tool that looks free today can quietly become your biggest expense once you succeed. Success should never accidentally bankrupt you.

3. How Much Say Does Your Team Really Have?

Control is a trade-off, not a free win. More control means more responsibility.

Sam wanted to self-host everything — "so we own our destiny." Alex pushed back: "We're a two-person team. If the server crashes at midnight, who's fixing it?"

They compromised: they used a managed database (less control, less burden) but hosted their own custom backend logic on a cloud server they controlled (more control where it actually mattered — their unique features).

The beginner lesson: don't ask "do we want control?" — of course you do. Ask "do we have the time and people to responsibly use that control?" A team of two rarely benefits from managing their own servers, load balancers, and security patches. A team of fifty engineers might.

4. Do You Need to Follow Any Regulations?

This is the one beginners skip entirely — until a customer's legal team emails them.

Alex and Sam's note app started getting interest from a healthcare company that wanted employees to store patient-related notes. Suddenly, "just store the text in a database" wasn't good enough. Healthcare data in many countries falls under strict rules (like HIPAA in the US) about who can access it, how it's encrypted, and how long it's kept.

They hadn't planned for this, and it meant weeks of re-work: encrypting data at rest, adding audit logs (a record of who accessed what and when), and picking a hosting region that met the requirement.

The beginner lesson: ask early — even if you think the answer is "no" — whether your app will touch health data, payment data, children's data, or data from users in regions with strict privacy laws (like the EU's GDPR). If there's any chance, design for it from day one. Retrofitting compliance is far more painful than building it in.

5. How Will You Recover If Something Goes Wrong?

This is the one that woke Alex up at 2 AM.

Their database provider did offer backups — but only if you turned the setting on, which they hadn't. A routine update accidentally deleted a table, and there was nothing to restore from.

A good backup strategy answers three questions:

How often do we back up? (Every hour? Once a day?)
How long do we keep backups? (A week? A year?)
How fast can we actually restore, and have we ever tested it?

That last point matters most. A backup you've never tried to restore isn't a backup — it's a hope.

The beginner lesson: backups aren't a "nice to have" you add later. They're a seatbelt — invisible until the one moment they save you completely.

6. Do You Actually Need a Custom Setup?

Most apps don't need anything exotic. A standard web server, a standard database, a standard hosting platform — that's enough for the vast majority of ideas.

Alex and Sam briefly considered building their own custom search engine for notes, from scratch, because "existing tools felt slow." They spent a week on it before realizing an existing open-source search tool did 95% of what they needed, for free, already battle-tested by thousands of other apps.

The beginner lesson: a custom environment (custom infrastructure, custom frameworks, custom anything) should be the last resort, not the first instinct. Ask: "does a standard, boring, well-tested tool already solve this?" Usually, it does. Save your custom-building energy for the one thing that actually makes your app special.

7. How Much Say Do You Need Over How It Behaves?

This is about how predictable and adjustable your app's behavior needs to be — especially relevant now that many apps use AI features.

Alex and Sam added an AI feature that auto-summarizes long notes. Early on, they used a third-party AI service with default settings. But they quickly found they had almost no control over how it summarized things — it sometimes changed the tone or missed key details, and they couldn't adjust it.

They switched to a setup where they could give the AI clear instructions and guardrails, giving them far more control over its behavior — while still not having to build the AI themselves.

The beginner lesson: figure out, for each major feature, whether you need tight control over exactly how it behaves (important for anything user-facing or safety-related) or whether "good enough, out of the box" is fine. Paying for more control only where it truly matters keeps you fast and safe.

Putting It All Together

None of these seven questions have a single correct answer. The right answer for Alex and Sam's two-person note-taking app is different from the right answer for a 200-person fintech company. What matters is that you ask the questions on purpose, before you're forced to answer them during an outage, a legal notice, or a surprise bill.

A simple way to remember them:

Question	What it protects you from
Where should the data be stored?	Slow, insecure, or inflexible systems
How will expenses scale?	A shocking bill at scale
How much say does the team have?	Burning out a small team
Any regulations to follow?	Legal trouble and lost trust
How will we recover from failure?	Losing everything in one bad moment
Do we need a custom setup?	Wasting time reinventing the wheel
How much say over its behavior?	Unpredictable, hard-to-fix features

Good architecture isn't about picking the fanciest tools. It's about picking tools that match your team, your budget, and your users — and being honest about the trade-offs before they become emergencies.

Stop Confusing SDK and API: The Difference Finally Explained (With Real-World Examples)

Md. Mehedi Hasan — Sun, 19 Jul 2026 20:33:32 +0000

SDK vs API: Explained with a Real Example (Manual Backend vs Supabase)

If you are learning backend development, you have probably heard two words a lot: API and SDK. Many beginners think they are the same thing. They are not.

In this article, we will understand the difference in very easy English, using a real example: building a simple "Sign Up" feature.

First, we will build it the manual way (like making our own backend with Express.js and a database).
Then, we will build the same thing using Supabase, which gives us a ready-made SDK.

By the end, you will clearly understand: What is an API? What is an SDK? And how SDK makes life easier?

1. What is an API? (Simple Explanation)

API means Application Programming Interface.

Think of an API like a waiter in a restaurant.

You (the frontend app) do not go inside the kitchen (the server/database) yourself.
You give your order to the waiter (the API).
The waiter goes to the kitchen, gets your food, and brings it back to you.

In technical words: An API is a set of rules that lets two applications talk to each other. Usually, this means sending a request (like "give me user data") and getting a response back (like the user data in JSON format).

A simple API call looks like this:

POST https://myapp.com/api/signup
Body: { "email": "test@example.com", "password": "12345" }

You are just sending a raw HTTP request. No special tool is required — you could even do this with a simple fetch() call, or using a tool like Postman.

2. What is an SDK? (Simple Explanation)

SDK means Software Development Kit.

Think of an SDK like a ready-made toolbox.

Instead of writing raw HTTP requests by hand (like calling the waiter yourself every time in a very formal way), the SDK gives you pre-written functions that do the API calling FOR you, behind the scenes.

So instead of writing this:

fetch("https://myapp.com/api/signup", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: "test@example.com", password: "12345" })
})

An SDK lets you simply write:

supabase.auth.signUp({ email: "test@example.com", password: "12345" })

Same result. Much easier to write.

Key point to remember:

An SDK is built ON TOP OF an API. The SDK is just a helper library that calls the API for you, so you don't have to write raw requests yourself.

3. Real Example: Manual Backend App (Building Sign Up Yourself)

Let's say you want to build a "Sign Up" feature completely by yourself, without any tool like Supabase.

You will need to do ALL of these steps manually:

Set up a server (Express.js)
Connect to a database (like PostgreSQL)
Write a route to accept sign-up data
Hash the password yourself (never store plain passwords!)
Save the user in the database
Create a login token (JWT) yourself
Send the response back

Here is what that looks like in code:

// server.js - Manual backend using Express.js

const express = require("express");
const bcrypt = require("bcrypt");
const jwt = require("jsonwebtoken");
const { Pool } = require("pg"); // PostgreSQL connection

const app = express();
app.use(express.json());

const db = new Pool({
  connectionString: "postgres://user:password@localhost:5432/mydb"
});

// Manual Sign Up Route (this itself IS an API endpoint)
app.post("/api/signup", async (req, res) => {
  const { email, password } = req.body;

  try {
    // Step 1: Hash the password ourselves
    const hashedPassword = await bcrypt.hash(password, 10);

    // Step 2: Save user to database ourselves
    const result = await db.query(
      "INSERT INTO users (email, password) VALUES ($1, $2) RETURNING id, email",
      [email, hashedPassword]
    );

    const newUser = result.rows[0];

    // Step 3: Create a login token ourselves
    const token = jwt.sign({ userId: newUser.id }, "SECRET_KEY", {
      expiresIn: "7d"
    });

    // Step 4: Send response back
    res.status(201).json({ user: newUser, token });

  } catch (error) {
    res.status(500).json({ error: "Something went wrong" });
  }
});

app.listen(3000, () => console.log("Server running on port 3000"));

What's happening here?

This whole /api/signup route is YOUR OWN API. You built it from scratch.
You had to think about password security, database structure, tokens — everything.
This works fine, but it takes a lot of time and knowledge to do correctly and safely.

This is what it means to build a backend manually, calling low-level tools directly.

4. Real Example: Same Sign Up Feature Using Supabase (SDK)

Now let's do the exact same thing using Supabase, which is a backend-as-a-service platform.

Supabase already has:

A database (PostgreSQL) ready for you
A complete authentication system (sign up, login, password reset)
A JavaScript SDK that wraps their APIs into simple functions

First, install their SDK:

npm install @supabase/supabase-js

Then connect to your Supabase project:

// supabaseClient.js

import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://your-project.supabase.co'
const supabaseKey = 'your-public-anon-key'

export const supabase = createClient(supabaseUrl, supabaseKey)

Now here is the ENTIRE sign-up feature:

// signup.js

import { supabase } from './supabaseClient'

async function signUpUser(email, password) {
  const { data, error } = await supabase.auth.signUp({
    email: email,
    password: password
  })

  if (error) {
    console.log("Error:", error.message)
    return
  }

  console.log("User created:", data.user)
}

signUpUser("test@example.com", "12345678")

That's it. Just a few lines.

What just happened?

No password hashing code written by you (Supabase's backend does it).
No database table setup for users needed (Supabase manages it).
No JWT token code written by you (Supabase creates and manages tokens).
You just called supabase.auth.signUp() — one simple SDK function.

5. So Where is the "API" in Supabase?

Here is the important part that connects everything together.

Even though you wrote supabase.auth.signUp(...), behind the scenes, the Supabase SDK is actually calling a real API for you. It's happening automatically, hidden from your eyes.

If you check your browser's network tab, you would actually see something like this happening automatically:

POST https://your-project.supabase.co/auth/v1/signup
Body: { "email": "test@example.com", "password": "12345678" }

This is the real API request. The SDK just wrote this request FOR you.

So the relationship is:

Your Code  →  SDK function (supabase.auth.signUp)  →  API request (POST /auth/v1/signup)  →  Supabase's Server

6. Side-by-Side Comparison Table

Feature	Manual Backend (Raw API)	Supabase (SDK)
Writing the server	You build it yourself	Already built for you
Database setup	You design tables, connect DB	Ready-made, just configure
Password security	You write hashing code	Handled automatically
Auth tokens (JWT)	You create and manage	Handled automatically
Code needed for sign up	~20-30 lines	~5 lines
Speed of development	Slow	Fast
Control over every detail	Full control	Less control, more convenience
What you're really using	Raw HTTP requests	Helper functions that call APIs internally

7. The Simplest Way to Remember This

API = the actual communication rule / request that goes from one app to another (like a raw letter you send).
SDK = a toolbox of ready-made functions that write and send that letter FOR you, so you don't have to write it by hand every time.

Every SDK uses an API internally. But not every API has an SDK.

Some APIs are "raw" — you must call them yourself using fetch() or similar tools (like our manual Express.js backend). Other services, like Supabase, Stripe, Firebase, and Twilio, give you an SDK so that using their API becomes much simpler and safer.

8. Final Thought

If you are learning backend development:

Building things manually first (like we did with Express.js) is a GREAT way to learn how things really work underneath.
Using SDKs (like Supabase) later is great for building real products faster, because you don't need to reinvent authentication, databases, and security every single time.

Both are useful skills. Understanding both means you truly understand how modern backend development works — from the ground up, and from the "easy tools" side too.

Vector search : Where meaning is matched, not keywords

Md. Mehedi Hasan — Mon, 13 Jul 2026 05:22:28 +0000

Ever wondered how searching "comfortable shoes for long walks" instantly finds the perfect pair—even when those exact words aren't in the product title?

Vector Search takes search to the next level by understanding the intent behind user queries. In this article, I break down how it works, where it's used, and when your application actually needs it, why it's becoming essential in modern AI applications, its benefits and challenges.

What is Vector Search?

Vector search is an AI-powered search technique that converts both user queries and stored data into numerical vectors (embeddings). Instead of matching words, it compares the meaning of the query with the meaning of the stored data and returns the closest results.

For example, searching "coat for snow" can return winter jackets, even if the word snow doesn't exist in the product title.

How Does It Work?

The process is simple:

Convert all products, documents, or images into vector embeddings.
Convert the user's search query into an embedding using the same AI model.
Compare the query embedding with stored embeddings using similarity algorithms such as Cosine Similarity or Euclidean Distance.
Return the most relevant results based on semantic similarity.

What Are Vectors and Embeddings?

A vector is simply a list of numbers representing the meaning of data.

An embedding is the AI-generated vector created from text, images, audio, or other data types. Similar content produces similar embeddings, making semantic search possible.

Popular embedding models include:

BERT
Word2Vec
GloVe

Benefits of Vector Search

✅ Better Search Results

Understands user intent instead of relying on exact keywords.

✅ Handles Unstructured Data

Works with text, images, videos, audio, and documents.

✅ Multilingual Search

Can match similar meanings across different languages.

✅ Personalized Experience

Learns user preferences to deliver more relevant recommendations.

✅ Powers AI Features

Used in chatbots, recommendation engines, virtual assistants, and Retrieval-Augmented Generation (RAG) systems.

Challenges

Although powerful, vector search comes with some trade-offs.

High computational and storage requirements
More complex implementation than traditional search
Choosing the right embedding model is critical
Harder to debug because results are based on semantic similarity
Requires careful handling of privacy and sensitive data

Common Use Cases

Vector search is widely used across industries, including:

🛒 E-commerce product search and recommendations
🤖 AI chatbots and customer support
📄 Document search and retrieval
🖼️ Image similarity search
🎤 Voice assistants
🏥 Medical image analysis
😊 Sentiment analysis
🔍 Hybrid search (keyword + vector search)

Should Every Application Use Vector Search?

Not necessarily.

For most applications, especially MVPs, traditional search combined with filters and full-text search is enough.

Vector search becomes valuable when you need semantic understanding, AI-powered recommendations, personalized experiences, or natural language search.

Final Thoughts

Vector search is changing how modern applications retrieve information. Instead of matching words, it understands meaning, making search more natural and accurate.

As AI continues to evolve, vector search is becoming a core technology behind intelligent applications—from e-commerce and recommendation systems to chatbots and enterprise search.

If you're building an AI-powered product, learning vector search is a skill worth investing in.

The `Never` type - the typeScript feature most developers ignore… Until It Breaks Their Code

Md. Mehedi Hasan — Wed, 17 Jun 2026 04:42:26 +0000

TypeScript is known for catching bugs before runtime.

But one of its most underrated features is the never type, especially for exhaustive type checking.

Most developers know void.

Fewer understand never.

Even fewer actually use it correctly.

Yet this tiny feature can prevent entire classes of bugs in production.

🔹 `void` vs `never` (Quick Reality Check)

void  → function finishes normally (no return value)
never → function never finishes normally (throws or infinite loop)

Example:

function logMessage(): void {
  console.log("Hello");
}

function throwError(): never {
  throw new Error("Something went wrong");
}

💥 The Real Problem (Missing Exhaustiveness)

We define a union type:

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "rectangle"; width: number; height: number }
  | { kind: "triangle"; base: number; height: number };

And write a function:

function getArea(shape: Shape): number {
  switch (shape.kind) {
    case "circle":
      return Math.PI * shape.radius ** 2;

    case "rectangle":
      return shape.width * shape.height;

    case "triangle":
      return (shape.base * shape.height) / 2;

    default:
      return 0;
      // ❌ Problem: TypeScript assumes this is fine
      // ❌ But we are NOT ensuring all cases are handled
  }
}

⚠️ Hidden Bug (When Type Changes)

Later, a new requirement comes:

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "rectangle"; width: number; height: number }
  | { kind: "triangle"; base: number; height: number }
  | { kind: "square"; side: number }; // NEW

Now our function is silently broken:

function getArea(shape: Shape): number {
  switch (shape.kind) {
    case "circle":
      return Math.PI * shape.radius ** 2;

    case "rectangle":
      return shape.width * shape.height;

    case "triangle":
      return (shape.base * shape.height) / 2;

    default:
      return 0;

      /*
        ❌ PROBLEM:
        - "square" is NOT handled
        - No TypeScript error
        - No warning
        - This will fail silently in production
      */
  }
}

🧠 The Fix: `never` (Exhaustive Checking)

We create a helper:

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`);
}

🔥 Safe Version (WITH `never` — Fully Exhaustive)

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "rectangle"; width: number; height: number }
  | { kind: "triangle"; base: number; height: number }
  | { kind: "square"; side: number }; // NEW SHAPE ADDED

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`);
}

function getArea(shape: Shape): number {
  switch (shape.kind) {
    case "circle":
      return Math.PI * shape.radius ** 2;

    case "rectangle":
      return shape.width * shape.height;

    case "triangle":
      return (shape.base * shape.height) / 2;

    default:
          return assertNever(shape);
      /*
        🔥 This is where magic happens

        If ANY new shape is added and NOT handled,
        TypeScript will throw an error here.
      */

  }
}

🚨 What Happens Now?

If someone adds:

{ kind: "square"; side: number }

TypeScript shows:

❌ Argument of type '"square"' is not assignable to parameter of type 'never'

🧠 Meaning of This Error

“You said you handled all cases… but you didn’t.”

📊 Before vs After Mental Model

❌ Without `never`

Type changes
   ↓
Switch not updated
   ↓
No TypeScript error
   ↓
💥 Bug reaches production

✅ With `never`

Type changes
   ↓
Switch not updated
   ↓
TypeScript compile error
   ↓
🛑 Bug stopped before runtime

💡 Why This Matters in Real Projects

This pattern is extremely useful in:

🧾 Payment systems
📦 Order status flows
👤 Role-based access control
🌐 API response handling
🎯 UI state machines

🚀 Final Thought

never is not just a TypeScript trick.

It is a compile-time safety guarantee for your business logic.

If you're not using exhaustive checking yet, you're only partially using TypeScript.

🧠 One-line summary

“If you're not using never for exhaustive checks, TypeScript is not fully protecting your logic.”