DEV Community: Md Mijanur Molla

Why Good Architecture Matters More Than Writing Perfect Code

Md Mijanur Molla — Sat, 02 May 2026 06:40:49 +0000

As developers, we spend a lot of time improving our code.

Writing clean functions
Following best practices
Using proper naming
Avoiding duplication

All good things.

But here’s a hard truth:

👉 Perfect code inside a bad architecture still leads to a bad system.

Let’s understand why 👇

💡 Code vs Architecture (Simple Difference)

Code = How you write logic
Architecture = How your system is structured

Code is local.

Architecture is global.

Code solves small problems.
Architecture decides how everything fits together.

💻 You Can Have Clean Code… and Still Fail

Imagine this:

Your code is clean
Functions are well-written
Naming is perfect

But:

Everything is tightly coupled
No separation of concerns
Hard to scale
Hard to modify

👉 The system becomes painful to work with

So even “good code” doesn’t save you.

⚠️ What Bad Architecture Looks Like

You might have seen this:

One huge backend file doing everything
Frontend directly depending on backend structure
No clear separation between modules
Changing one feature breaks another

👉 That’s an architecture problem, not a coding problem.

🔄 Why Architecture Matters More Over Time

Here’s the key:

👉 Code quality matters today
👉 Architecture quality matters tomorrow

As your app grows:

More features are added
More developers join
More data flows through the system

If architecture is weak:

👉 Everything slows down

🚧 Real Example

Feature request:

👉 “Add one small field to user profile”

With good architecture:

Change one module
Everything works

With bad architecture:

Change multiple files
Unexpected bugs
Testing becomes painful

👉 Same feature, very different effort

⚙️ Architecture Enables Scalability

Good architecture helps you:

Scale users
Scale features
Scale team collaboration

Bad architecture:

Slows development
Creates technical debt
Makes future changes harder

🧠 Clean Code vs Good Architecture

Clean code:

Readable
Maintainable
Easy to understand

Good architecture:

Flexible
Scalable
Decoupled
Easy to extend

👉 You need both, but architecture has bigger impact.

💀 Why Developers Ignore Architecture

Because:

It’s not immediately visible
It doesn’t break instantly
It feels “extra work”

But later…

👉 It becomes the biggest problem

🔥 Architecture Fails Slowly

This is important:

Bad code breaks fast.
Bad architecture breaks slowly.

At first:

Everything works

After some time:

Changes become harder
Bugs increase
Development slows

👉 That’s when the pain starts

🎯 What Good Architecture Gives You

Clear structure
Independent modules
Easy testing
Easy scaling
Faster development over time

👉 It makes your system future-proof

🚀 How to Think Better as a Developer

Instead of only asking:

👉 “Is my code clean?”

Start asking:

Can this system scale?
Can I change this easily later?
Is everything tightly coupled?
Can new developers understand this?

👉 That’s architectural thinking

💡 Final Thought

Writing perfect code is important.

But building a system that survives growth…

👉 That’s what real engineering is about.

Because in the long run:

👉 Systems don’t fail because of bad syntax
👉 They fail because of bad design

And that’s why good architecture matters more 💙

How to Build Your Own LLM (Without Spending Millions)

Md Mijanur Molla — Fri, 01 May 2026 11:12:44 +0000

Everyone is talking about LLMs.

ChatGPT, Gemini, Claude…

And a common question developers have is:

👉 “Can I build my own LLM?”

The answer is:

👉 Yes… but not the way you think.

Let’s break it down in a practical way 👇

💀 The Truth About “Building an LLM”

Training a model like GPT from scratch requires:

Massive datasets (billions of tokens)
High-end GPUs (A100, H100)
Huge cost (millions of dollars)

👉 Not practical for individual developers

So instead of reinventing the wheel…

👉 Smart developers build on top of existing models

💡 3 Practical Ways to Build Your Own LLM

🧠 1. Fine-Tuning an Existing Model

You take an existing model and train it on your own data.

Example:

Customer support chatbot
Domain-specific assistant
Resume analyzer

Tools you can use:

Hugging Face Transformers
LoRA / PEFT techniques

👉 This is how most real-world AI apps are built

⚙️ 2. RAG (Retrieval Augmented Generation) — Best Option

This is the most practical approach.

Instead of training the model…

👉 You give it access to your data

Flow:

Store your data (PDFs, docs, DB)
Convert into embeddings
Store in vector database
LLM retrieves relevant data and answers

Tools:

LangChain
LlamaIndex
Vector DB (Pinecone, FAISS)

👉 Fast, cheap, powerful

💻 3. Run Local LLM

You can run models locally using:

Ollama
LM Studio

Example models:

LLaMA
Mistral
Phi

Now you have your own AI running on your machine.

No API cost.

🚀 Example: Build Your Own AI Assistant

Simple architecture:

User → API → LLM → Response

With RAG:

User → API → Vector DB → LLM → Response

👉 This is how modern AI apps work

⚡ When Should You Build Your Own LLM?

You should do this when:

You want domain-specific AI
You need private/local data
You want to reduce API cost
You’re building AI products

⚠️ Common Mistakes

Trying to train from scratch ❌
Ignoring data quality ❌
Not understanding use case ❌

👉 Focus on solving problems, not just building models

🎯 Key Insight

You don’t need to build a giant LLM.

👉 You need to build a system around LLMs

That’s where real value is.

🚀 Final Thought

The future is not:

“Who can train the biggest model”

But:

👉 “Who can use LLMs smartly to solve real problems”

Start small.

Build smart.

And you’ll already be ahead 💙

I Created an Elevator Challenge… And the Lift Kept “Coming” Forever 🛗😭

Md Mijanur Molla — Thu, 30 Apr 2026 05:11:16 +0000

You press the lift button.

Display shows:

“Lift is coming.”

You wait.

30 seconds…

1 minute…

Still not here.

👉 But system says it’s coming.

So I turned this into a coding challenge.

And yes…

This is a real engineering problem.

🛗 The Problem

Basic logic:

User requests lift
Lift moves to floor
Request completed

Simple.

But real buildings are not simple.

⚠️ What Goes Wrong?

In real systems:

• Multiple requests come at once

• Lift keeps changing direction

• Some floors get priority

• Some requests get delayed forever

And suddenly:

👉 Lift feels stuck in another universe.

🧠 What I Observed

When exploring this:

Basic queue logic works
But inefficient scheduling causes delay
Some floors get ignored
System feels slow and unfair

The code works.

But the experience is frustrating.

🔍 The Real Issue

This is not just movement.

It’s about:

• Scheduling

• Optimization

• Fairness

• Real-time decisions

Because:

👉 Serving requests in order is not always optimal.

💡 What Better Systems Do

Real elevator systems use:

Direction-based scheduling
SCAN (elevator algorithm)
Priority handling
Efficient routing

This ensures:

👉 Faster response

👉 Fair service

👉 Less waiting

🔥 Try My Challenge

I turned this into a challenge on VibeCode Arena.

👉 Try it here:
https://vibecodearena.ai/duel/0999a34f-d23e-4156-ae0a-0f5168a49fd2

Can you:

Fix slow lift logic?
Improve scheduling?
Build a smarter elevator system?

🎯 Final Thought

Some systems move data.

Some systems move people.

And this one…

👉 Moves very slowly 😭

Tell me 👇

What’s worse:

Waiting for lift

watching it stop on every floor except yours? 😭

I Created a Restaurant Waitlist Challenge… And My Table Was “Almost Ready” Forever 🍽️😭

Md Mijanur Molla — Wed, 29 Apr 2026 13:14:37 +0000

You’ve heard this before.

“Sir, table will be ready in 5 minutes.”

You smile.

You wait.

10 minutes.

20 minutes.

45 minutes later…

Host says:

Almost ready.

Still almost ready. 💀

So I turned this into a coding challenge.

And surprisingly…

This is a real system design problem.

🍽️ The Problem

The logic looks simple:

Add guests to a waitlist
Assign tables
Update status

Done.

Seems straightforward.

But real restaurants are chaos.

⚠️ What Goes Wrong?

In real systems:

• Tables take longer than expected

• Guests stay longer than predicted

• Wait estimates become wrong

• Queue order may not be fair

• Some people feel stuck forever

And suddenly:

👉 “5 minute wait” becomes 50 minutes.

Sound familiar? 😅

🧠 What I Observed

When exploring this problem:

Basic solutions track a queue
Many ignore changing table availability
Some miss fairness problems
Very few handle dynamic wait predictions

The code works.

But the experience lies.

🔍 The Real Issue

This is not just queue logic.

It’s about:

• Scheduling

• Dynamic prediction

• Fairness

• Uncertainty handling

Because:

👉 Wait time is not a fixed calculation.

It changes constantly.

💡 What a Better System Needs

A smarter waitlist system should consider:

Real table turnover data
Dynamic ETA updates
Queue fairness rules
Party size optimization
Better prediction models

This ensures:

👉 Fewer fake wait estimates

👉 Better customer trust

👉 Less “almost ready forever” trauma

🔥 Try My Challenge

I turned this into a challenge on VibeCode Arena because honestly…

This bug deserved investigation 😂

👉 Try it here:

https://vibecodearena.ai/duel/7298cb69-747f-4f0b-ae7a-ace9df8690e5

Can you:

Fix inaccurate wait times?
Build fairer queue logic?
Stop the “almost ready forever” bug?

🎯 Final Thought

Some bugs crash systems.

Some bugs waste weekends.

This one…

👉 Makes people hungry and angry.

Tell me honestly 👇

What lasts longer:

Restaurant waitlists

“5 more minutes” promises? 😭

Your Portfolio Is Probably Missing This One Thing (And It Matters More Than You Think)

Md Mijanur Molla — Tue, 28 Apr 2026 12:13:27 +0000

A lot of developers spend weeks building portfolios.

They add:

Projects ✅
Skills section ✅
GitHub links ✅
Nice UI ✅

And still…

👉 It doesn’t stand out.

Why?

Because many portfolios are missing one thing that matters a lot:

💡 Context.

Or more specifically:

👉 The story behind your projects.

And trust me…

This matters more than you think.

💻 Most Portfolios Look Like This

Project Card 1
Project Card 2
Project Card 3

Tech stack:

React
Node.js
MongoDB

Looks good.

But there’s a problem.

It tells me what you built

Not:

👉 Why you built it
👉 What problem it solves
👉 What challenges you faced

And that’s where strong portfolios become different.

🎯 Recruiters Don’t Just Want Projects

They want proof you can think.

A project title alone doesn’t show that.

Example:

❌ “Built Job Portal using MERN”

Okay…

But so what?

Now compare:

✅ Built a job portal solving fragmented job discovery for freshers, with search filters, role-based auth, and scalable backend APIs.

Very different signal.

One shows code.

One shows engineering thinking.

🧠 What Your Portfolio Should Include

For every serious project, add:

1. Problem Statement

What problem were you solving?

Not:

“I built a chatbot”

Instead:

“I built a chatbot to simplify candidate support queries.”

Huge difference.

2. Architecture Thinking

Show how you designed it.

Talk about:

Frontend
Backend
Database
APIs
Deployment

Now you sound like a builder.

Not just a coder.

3. Challenges You Faced

This is massively underrated.

Talk about:

Bugs you solved
Scaling issues
Performance fixes
Deployment problems

Because real projects have struggles.

And solving them is experience.

4. Tradeoffs You Made

This is advanced… and powerful.

Example:

👉 Used JWT instead of sessions because…

That shows decision making.

Recruiters love that.

5. Live Demo + Proof

Please…

Don’t just show GitHub.

Show:

Live demo
Screenshots
Demo video
README
Use cases

A project people can try > a repo people may never open.

🔥 Projects Don’t Impress.

Project Thinking Impresses.

Read that again.

Anyone can clone a project.

Not everyone can explain:

Why it exists
Why it was designed that way
Why choices were made

That’s what makes portfolios memorable.

💀 Common Portfolio Mistake

Many developers think:

More projects = better portfolio

Not always.

3 strong projects with depth
can beat

10 shallow projects.

Every time.

⚡ Think Product, Not Assignment

Don’t present projects like college submissions.

Present them like products.

Instead of:

“Task App”

Say:

“Task management tool built to solve team workflow tracking.”

Sounds completely different.

Because it is.

🚀 A Better Portfolio Formula

Try this:

Project + Problem + Architecture + Challenges + Demo

That combination is gold.

💡 Final Thought

Most portfolios focus on showing code.

Great portfolios show thinking.

And in interviews…

Thinking often matters more.

So if your portfolio feels incomplete…

Maybe you don’t need another project.

👉 You may just need better storytelling around the projects you already have.

And honestly…

That might be the missing piece 💙

💬 What do you think every developer portfolio should include?

Live demos?
Case studies?
Architecture diagrams?

Let’s discuss 👇

Portfolio #Developers #SoftwareEngineering #WebDevelopment #BuildInPublic #CareerAdvice #GitHub

🔐 The Hidden Engineering Behind a Simple Login Button

Md Mijanur Molla — Mon, 27 Apr 2026 10:48:26 +0000

It looks so simple.

You click:

Login

And within seconds…

👉 You’re inside the app.

Easy, right?

Not really.

Behind that one tiny button…

There’s a surprising amount of engineering happening.

Let’s break down what really happens 👇

💡 It Starts With a Form

You enter:

Email
Password

And click login.

Simple user action.

But under the hood…

Things are just getting started.

📡 Step 1: A Request Is Sent

Your app sends an API request to the server:

```http id="r4pj4o"
POST /login




Along with:

* Credentials
* Headers
* Authentication data

👉 This is where frontend hands control to backend.

---

## 🔍 Step 2: Input Validation

Before anything else…

The server checks:

* Is email valid?
* Is password empty?
* Any malicious input?

Because security starts early.

Not after login.

---

## 🔐 Step 3: Password Verification

Here’s something important:

Your actual password usually is **not stored directly**.

Instead:

* Stored as hashed value
* Compared securely using algorithms like bcrypt

Server checks:

👉 Does entered password match stored hash?

If yes…

Move forward.

---

## 🧠 Step 4: Authentication Happens

Now system confirms:

👉 You are really you.

This may involve:

* Sessions
* JWT tokens
* OAuth flows

This is where “logged in” begins.

---

## 🍪 Step 5: Session or Token Is Created

Once authenticated:

System often creates:

* Session cookie
  or
* Access token

This is how app remembers you.

Otherwise you’d need to login every request 😅

---

## 🛡️ Step 6: Security Checks

Modern login often includes extra checks:

* Rate limiting
* Suspicious login detection
* MFA / OTP
* Device verification

Because login is a major attack target.

---

## 🗄️ Step 7: User Data Loads

After login succeeds:

Backend may fetch:

* Profile data
* Permissions
* Roles
* Preferences

Example:

Admin and regular user may see different dashboards.

---

## ⚙️ Step 8: Authorization Starts

Authentication says:

👉 You are a user.

Authorization says:

👉 What you can access.

Huge difference.

Often confused.

Very important.

---

## 🚀 Step 9: Redirect + App State Updates

Now frontend updates:

* User marked as logged in
* Protected routes unlocked
* Dashboard loads

And only now…

You “see” login success.

---

# 🔄 Full Flow

Login Click → API Request → Validation → Password Check → Auth → Token/Session → Security Checks → User Data → Dashboard

All behind one button.

---

## ⚠️ Things That Can Go Wrong

A lot.

* Wrong credentials
* Expired token
* Server issues
* Weak password storage
* Broken session handling

That tiny login button carries serious complexity.

---

## 🤯 And We Didn’t Even Cover…

Things like:

* Social login with Google
* OAuth flows
* CSRF protection
* Refresh tokens
* Single Sign-On
* Distributed authentication

That rabbit hole goes deep.

Very deep.

---

## 🎯 Why This Matters

As developers, it changes how you think.

A login button is not:

❌ Just a form

It’s:

✅ Security
✅ Backend logic
✅ State management
✅ User identity system

That’s engineering.

---

## 🚀 Final Thought

Some of the hardest engineering problems…

Hide behind the simplest UI.

A tiny login button may look ordinary.

But behind it?

👉 Authentication systems
👉 Security layers
👉 Distributed logic
👉 Trust

And that’s the beauty of software engineering 💙

I Created a Ride Fare Challenge… And a 2km Trip Cost ₹487 🚕😭

Md Mijanur Molla — Mon, 27 Apr 2026 08:03:02 +0000

You open a cab app.

Destination:

2 km away.

Expected fare?

Maybe ₹70.

Actual fare?

₹487

At that point…

Walking starts looking premium. 😅

So I turned this into a coding challenge.

And yes…

This is a real system problem.

🚨 The Problem

Basic fare logic sounds easy:

Calculate distance fare
Add surge pricing
Add weather charges

Done.

Right?

Not really.

⚠️ What Goes Wrong?

In real ride apps:

• Demand spikes suddenly

• Driver supply drops

• Surge multipliers stack badly

• Weather fees pile up

And suddenly:

👉 A short ride costs like airport travel.

Users feel pricing is random.

Sometimes… it almost is.

🧠 What I Observed

When exploring this:

Basic solutions handled formula math
Many ignored pricing caps
Some missed fairness logic
Very few thought about trust in pricing

The code works.

But users feel robbed 😭

🔍 The Real Issue

This is not just fare calculation.

It’s about:

• Dynamic pricing

• Fairness

• Supply-demand modeling

• User trust

Because:

👉 Correct math can still produce terrible pricing.

💡 What Better Systems Need

A smarter fare engine should include:

Surge caps
Fairness constraints
Dynamic but bounded pricing
Transparency rules
Prediction smoothing

This ensures:

👉 Fewer pricing shocks

👉 Happier users

👉 Less rage-closing the app

🔥 Try My Challenge

I turned this into a challenge on VibeCode Arena.

👉 Try it here:
https://vibecodearena.ai/duel/bcde820c-cf40-432b-ae57-7df3b3d51d13

Can you:

Fix crazy surge pricing?
Prevent absurd fares?
Build a fairer pricing system?

🎯 Final Thought

Some algorithms optimize systems.

Some optimize users into walking.

This one…

👉 Might be doing both. 😭

Tell me honestly:

What’s worse?

Surge pricing…

or seeing fare increase while you're watching it? 👀

Why Your Project Needs a Live Demo (Not Just GitHub) — And Where to Deploy It Free

Md Mijanur Molla — Sat, 25 Apr 2026 05:44:50 +0000

A lot of developers build good projects…

Push code to GitHub…

And stop there.

Then during interviews, recruiters ask:

👉 “Can I see the live project?”

And many candidates say:

“Only source code is available…”

Big mistake.

Because in many cases,

👉 A deployed project creates a much stronger impression than source code alone.

Let’s talk about why live links matter, and where you can host projects for free 👇

💀 The Problem With “Only Source Code”

Let’s be honest.

Most recruiters will not:

Clone your repository
Install dependencies
Run your project locally
Debug your setup issues

They simply don’t have time.

If all you share is code…

There’s friction.

And friction hurts attention.

🤯 Why Live Demo Matters in Interviews

A live project shows:

Your project actually works
You can deploy real applications
You understand production basics
Your work is demo-ready

That signals maturity.

Not just coding ability.

👉 It makes you look closer to a real software engineer.

💡 Source Code Shows Skill

🚀 Live Demo Shows Execution

Huge difference.

Anyone can have a repository.

Not everyone ships.

And companies value people who ship.

🎯 Why Deploying Your Project Matters

1. It Makes Your Project Real

A project running on the internet feels like a product.

Not an assignment.

Big difference.

2. Interviewers Can Test It Instantly

Instead of saying:

“Please run the repo”

You can say:

👉 “Here’s the live link.”

Much stronger.

3. It Shows End-to-End Knowledge

Deployment means you’ve touched:

Hosting
Domains
Environment variables
Build process
Production issues

That matters.

4. You Discover Real Bugs

Fun fact:

Many bugs appear only after deployment 😅

Classic:

👉 “Worked locally…”

Production:
💀

Deployment teaches things tutorials don’t.

5. Portfolio Looks 10x Better

GitHub + live demo + README

That combo hits differently.

🆓 Free Platforms to Deploy Your Projects

And yes…

You do NOT need money.

There are amazing free options.

🌐 Frontend Hosting

Vercel

Perfect for:

React
Next.js
Frontend apps

Why developers love it:

Very easy deploy
GitHub integration
Auto deployment on push
Free SSL
Great performance

Push to GitHub → connect → deploy.

Done.

⚡ Netlify

Great for:

Static sites
Frontend apps
Portfolios

Features:

Free hosting
Forms support
Serverless functions
Simple drag and drop deploy

Very beginner friendly.

🚀 GitHub Pages

Perfect for:

Portfolio sites
Static websites
Documentation projects

Very underrated.

And free.

🛠 Full Stack / Backend Hosting

☁️ Render

Great for:

Node.js apps
APIs
Full-stack projects
Databases

Very popular for student projects.

⚡ Railway

Super developer-friendly.

Great for:

Backend apps
Databases
Full stack deployments

Very smooth experience.

🐳 Fly.io

Great if you want to experiment with modern deployments.

Especially nice for containerized apps.

💻 Good Deployment Combos

MERN Project

Frontend → Vercel
Backend → Render
Database → MongoDB Atlas Free Tier

Free stack.

Powerful stack.

Static Portfolio

Use:

Netlify or
GitHub Pages

Done in minutes.

🔥 Bonus: Add These to Impress Interviewers

Along with live link, add:

Demo credentials (if login needed)
Screenshots in README
Architecture diagram
Deployment instructions

Small things.

Big impact.

⚠️ Common Mistake Developers Make

They think:

“Source code is enough.”

Often…

It isn’t.

Because recruiters evaluate outcomes.

Not effort.

🚀 Real Truth

A deployed project says:

👉 I can build

GitHub says:

👉 I can code

Companies want both.

🧠 Final Thought

Don’t let your project stay trapped in a repository.

Ship it.

Deploy it.

Make it live.

Because a project people can use…

is always stronger than a project people can only read.

And honestly?

Sometimes a live demo can impress more than your resume 💙

💬 What do you use for free deployments?

Vercel?
Netlify?
Render?

Let’s discuss 👇

WebDevelopment #Deployment #SoftwareEngineering #Projects #GitHub #Vercel #Netlify #BuildInPublic

I Created an “Undo Send” Challenge… And the Message Still Got Sent 😬

Md Mijanur Molla — Sat, 25 Apr 2026 04:27:15 +0000

You know that moment.

You send a message.

Then instantly realize…

👉 You should NOT have sent that.

So you hit Undo at lightning speed.

Relief.

…or so you think.

Now imagine the system says message undone.

But it still gets delivered.

💀

That’s not just embarrassing.

That’s a bug.

So I turned this into a coding challenge on VibeCode Arena.

And honestly…

This one got too real.

🚨 The Problem

The logic sounds simple:

User sends message
System delays delivery for a few seconds
User can click Undo before it sends

Looks perfect.

But there’s a hidden problem.

⚠️ What Can Go Wrong?

In real systems:

• Undo is clicked but send job still executes

• Delayed task was already scheduled

• Cancellation doesn’t stop background process

• Race conditions decide whether message survives

And suddenly:

👉 “Undo” lies.

👉 Message still goes out.

👉 Your panic becomes permanent.

😂 This Is Funny…

Until you realize it’s a real distributed systems problem.

Because “Undo Send” is not really unsending.

It’s usually:

👉 Delayed sending.

And that changes everything.

🧠 What I Observed

When exploring this challenge:

Basic solutions added delay
Some added undo flag
Many ignored race conditions
Very few handled cancellation safely

The code works.

But under timing pressure?

It breaks.

🔍 The Real Issue

This is not just messaging logic.

It’s about:

• Scheduled jobs

• Cancellation logic

• Race conditions

• Reliability under timing conflicts

Because:

👉 “Undo” is meaningless if the send job already escaped.

💡 What a Better System Needs

A proper Undo Send system should use:

Delayed job queue
Cancellation tokens
Job invalidation before execution
Reliable scheduler checks

This ensures:

👉 Undo actually undoes.

And saves lives. 😅

🔥 Try My Challenge

I turned this into a challenge because it mixes:

Real engineering
Timing bugs
And emotional damage

👉 Try it here:
https://vibecodearena.ai/duel/cf2fd567-b2c4-4518-8118-0f839691f685

Can you:

Fix fake Undo Send?
Prevent accidental delivery?
Build a reliable delayed-send system?

🎯 Final Thought

Some bugs crash servers.

Some bugs ruin weekends.

This one…

👉 Can ruin relationships. 😭

So tell me 👇

Have you ever trusted “Undo Send” a little too much? 😅

Why CI/CD Changed Software Development Forever

Md Mijanur Molla — Fri, 24 Apr 2026 11:16:48 +0000

There was a time when deploying software was scary.

Really scary.

Developers would write code for weeks…

Then manually deploy everything at once and pray:

👉 “Hope nothing breaks in production.”

Sometimes it worked.

Sometimes…

Production exploded 💀

That’s exactly the problem CI/CD helped solve.

Let’s break it down simply 👇

💀 Before CI/CD: Releases Were Painful

Earlier, shipping software often looked like this:

Developers wrote code for weeks
Changes piled up
Big release day arrived
Team manually deployed everything

And then:

Unexpected bugs
Broken builds
Failed deployments
Long downtime

👉 Releasing software felt risky.

⚠️ Common Problems Before CI/CD

Without automation:

Testing was often manual
Bugs were caught late
Deployments were error-prone
Rollbacks were messy
“Works on my machine” became a lifestyle

Sound familiar? 😅

💡 What is CI/CD?

CI/CD stands for:

✅ Continuous Integration (CI)

Developers push code frequently.

Every change automatically:

Builds the project
Runs tests
Checks if anything broke

👉 Problems are caught early.

🚀 Continuous Delivery / Deployment (CD)

After code passes checks:

It can be:

Prepared for release automatically
Or deployed automatically

👉 Shipping becomes faster and safer.

🔄 What Happens in a CI/CD Pipeline?

Typical flow:

Code Push → Build → Test → Security Checks → Deploy

Simple idea.

Powerful impact.

🧠 Why This Changed Everything

Before:

❌ Big risky releases

Now:

✅ Small frequent safe releases

That changes software development completely.

⚡ Real Benefits of CI/CD

Faster Development

Developers ship features quicker.

No waiting for huge release cycles.

Better Code Quality

Automated tests catch issues early.

👉 Less broken code reaching users.

Safer Deployments

Every deployment follows a repeatable process.

No random manual mistakes.

Faster Bug Fixes

Critical issue?

Push fix.

Pipeline runs.

Deploy.

Done.

💻 Real-World Example

Imagine updating a payment feature.

Without CI/CD:

Manual tests
Manual deploy
High risk

With CI/CD:

Push code
Tests run automatically
Deploy safely

Huge difference.

🛠 Tools You’ve Probably Heard Of

Popular CI/CD tools:

GitHub Actions
GitLab CI/CD
Jenkins
CircleCI

Different tools.

Same mission:

👉 Automate software delivery.

🔥 Why Modern Teams Can’t Ignore It

Today apps update constantly.

Think about:

Netflix
Amazon
Spotify

They can’t do manual deployments all day.

CI/CD makes modern scale possible.

⚠️ Is CI/CD Just for Big Companies?

No.

Even small projects benefit.

Because automation early saves pain later.

Huge lesson.

🎯 The Big Shift

CI/CD changed development from:

❌ “Deploy carefully and hope”

✅ “Deploy confidently and often”

That’s a mindset shift.

Not just a tool shift.

🚀 Final Thought

CI/CD didn’t just make deployments faster.

👉 It changed how software gets built.

Less fear.
More automation.
Faster delivery.

And honestly…

Modern software would look very different without it 💙

Why Every Modern Project Uses Docker (And Why You’re Struggling Without It)

Md Mijanur Molla — Thu, 23 Apr 2026 12:51:15 +0000

If you’re a developer…

You’ve probably faced this at least once:

👉 “It works on my machine… but not on yours”

And suddenly:

Your app breaks on another system
Dependencies mismatch
Version conflicts everywhere

Frustrating, right?

This exact problem is why Docker became so popular.

Let’s understand it in a simple way 👇

💀 Before Docker: The Pain Was Real

Earlier, running a project was messy.

You had to:

Install the correct Node/Python/Java version
Set up dependencies manually
Configure environment variables
Match OS differences

And even after doing everything…

👉 It still might not work

Why?

Because:

Your system ≠ other developer’s system
Your environment ≠ production environment

👉 Same code, different results

🤯 Real Problems Developers Faced

❌ “Works on my machine” issue
❌ Dependency hell
❌ Difficult onboarding for new developers
❌ Production bugs due to environment mismatch
❌ Time wasted in setup instead of coding

👉 Development became slower than it should be

🐳 Enter Docker: The Game Changer

Docker solved this with one simple idea:

👉 “Package everything together”

Instead of sharing just code…

You share:

Code
Dependencies
Runtime
Environment

👉 All inside a container

📦 What is Docker (Simple Terms)

Docker = a tool to create containers

A container is like:

👉 A mini portable environment
👉 That runs exactly the same everywhere

⚡ What Changes After Using Docker

Now:

You don’t install everything manually
You don’t worry about versions
You don’t face environment issues

Just:

docker run your-app

👉 And it works

Same on:

Your laptop
Your teammate’s system
Production server

🚀 Real Benefits of Docker

✅ Consistent environment everywhere
✅ Faster project setup
✅ Easy onboarding (new devs start in minutes)
✅ Fewer production bugs
✅ Better scalability

👉 Less setup, more building

🧠 Simple Example

Without Docker:

👉 “Install Node v18, then this, then that…”

With Docker:

👉 “Run this container”

Done.

⚠️ Is Docker Always Perfect?

Not exactly.

Slight learning curve
Extra layer of abstraction
Needs basic understanding of containers

But once you get it…

👉 You won’t go back

🎯 When You Should Use Docker

Use Docker when:

Working in teams
Building real-world projects
Deploying apps
Managing multiple services

👉 Basically… almost always in modern development

🚀 Final Thought

Docker didn’t just solve a problem.

👉 It changed how we build and run software

From:
❌ “Works on my machine”

To:
✅ “Works everywhere”

And that’s why Docker is a must-know skill today 💙

I Built a “Delivered but Not Received” System… And It Lied to Me 👻

Md Mijanur Molla — Thu, 23 Apr 2026 07:13:08 +0000

You’ve seen this.

Message sent ✔️

Delivered ✔️

But the other person says…

👉 “I didn’t get your message.”

Now you’re confused.

Was it delivered or not?

So I turned this into a coding challenge.

And it exposed a real problem.

😂 The Problem

The logic looks simple:

Send message
Mark it as delivered
Later mark it as received

That’s it.

But real systems are not that reliable.

⚠️ What Goes Wrong?

In real-world apps:

• Message marked as delivered without actual confirmation

• Network delay causes incorrect status

• Receiver never actually gets the message

• System shows false success

And suddenly:

👉 System says “Delivered”

👉 Reality says “Not received” 😭

🧠 What I Observed

When thinking about this:

Basic systems assume delivery = success
No real acknowledgment from receiver
No retry mechanism
No verification step

The code works.

But the truth?

👉 It creates illusion.

🔍 The Real Issue

This is not just about ticks.

It’s about:

• Delivery guarantees

• System reliability

• Network uncertainty

• Trust in communication

Because:

👉 “Delivered” should mean actually delivered

💡 What a Better System Needs

A proper messaging system should:

Wait for receiver acknowledgment
Retry failed deliveries
Handle network failures
Confirm actual receipt

This ensures:

👉 No false delivery

👉 No confusion

👉 Better trust

🔥 Try My Challenge

I created this for fun (and reality check 😄).

👉 Try it here:
https://vibecodearena.ai/duel/b84ff69c-72fb-47ab-aa0d-f599218a2e19

Can you:

Fix false delivery status?
Ensure real message receipt?
Build a reliable messaging system?

🎯 Final Thought

Some systems show status.

Some systems show truth.

And this one…

👉 Sometimes shows illusion 👻

So tell me 👇

Was it really delivered… or just marked as delivered? 😭