From MERN to Laravel: Why I'm Learning PHP and PostgreSQL as a MERN Developer published: false tags: laravel, php, postgresql, webdev

Zahid Hasan Tonmoy — Mon, 14 Sep 2026 06:33:14 +0000

If you'd told me a couple of years ago that I'd spend my evenings writing PHP, I would've laughed it off. I built my whole identity as a developer around MERN — MongoDB, Express, React, Node. It was fast, it was JavaScript top to bottom, and it felt like the "modern" stack compared to what a lot of local agencies were still running.

So it's a little funny to be sitting here now, a few months into learning Laravel and PostgreSQL, actually enjoying it. This isn't a "PHP was secretly amazing the whole time" post. It's more of an honest breakdown of why I started, what's been genuinely harder than I expected, and what's actually made me a better developer in the process.

Why bother, if MERN already works

Two things pushed me here.

First, the job and freelance market. I'm based in Dhaka, and if you look at what local agencies, small businesses, and even a lot of remote clients are actually running, PHP is everywhere. Laravel specifically shows up constantly in job posts and freelance briefs here — way more than I expected when I was deep in my MERN bubble. Sticking to one stack was quietly shrinking the pool of work I could take on.

Second, and this one surprised me more — I wanted to actually understand a relational database properly. I'd built a handful of projects on MongoDB, and I realized I'd never really had to think hard about schema design, foreign keys, or joins. MongoDB lets you get away with a lot of "figure it out later" thinking. I wanted to know what I was missing.

The parts that messed with my head

Coming from Mongoose, Eloquent felt oddly strict at first. In Mongoose, your schema is basically a suggestion:

// Mongoose — schema is more of a guideline
const productSchema = new mongoose.Schema({
  name: String,
  price: Number,
  tags: [String], // add whatever, whenever
});

In Laravel, the database is the source of truth, and migrations force you to commit to a structure before you write a line of app logic:

// Laravel migration — schema is law
Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->decimal('price', 8, 2);
    $table->foreignId('category_id')->constrained();
    $table->timestamps();
});

That foreignId()->constrained() line is such a small thing, but it represents a mindset shift I didn't expect. In MongoDB, "relationships" are usually just an ID you remember to populate correctly in your app code. In PostgreSQL, the database itself refuses to let you insert a product with a category that doesn't exist. The first time a constraint error caught a bug I would've silently shipped in MERN, I actually said "huh" out loud at my desk.

Artisan took some getting used to too. php artisan make:model Product -m scaffolds a model and migration in one command, and there's a generator for basically everything — controllers, requests, seeders, jobs. Coming from hand-rolling most of my Express boilerplate, it felt like cheating at first. Now I just think of it as Laravel handling the parts of backend dev that were never interesting anyway.

Blade was the smallest adjustment, honestly, mostly because I'd already done enough server-rendered work to not be precious about JSX. It's just PHP mixed into HTML with some sugar on top — @if, @foreach, component includes. Nothing revolutionary, but nothing to fight either.

What I'm not giving up

I want to be clear this isn't a "MERN was a phase" post. I'm still building with React and Node, and most of what I've shipped so far leans on that stack — a machine-learning-backed gold price predictor, a peer-to-peer file sharing tool built on WebRTC, an IoT drainage monitoring setup running on an ESP32 feeding into Firebase. None of that goes away.

What's changed is that I stopped treating "the stack" as a personality trait. Laravel and PostgreSQL are just more tools now, and honestly, having both a document-store mental model and a relational one makes me design better MERN apps too. I catch myself asking "should this actually be normalized?" in Mongoose schemas now, which never used to occur to me.

If you're a MERN dev thinking about doing the same

A few things that would've saved me time:

Don't fight Eloquent relationships — learn hasMany, belongsTo, and belongsToMany properly before building anything. Half of Laravel's "magic" is just these three.
Migrations are version control for your schema. Treat them like git commits — small, descriptive, one change at a time.
php artisan tinker is basically a Node REPL for your Laravel app. Use it constantly to test queries before wiring them into controllers.
PostgreSQL's EXPLAIN ANALYZE is worth learning early. Coming from Mongo, I never had to think about query performance this explicitly.

Where this is heading

I'm still early — a few real projects deep, not an expert by any stretch. But I'm at the point where I'd genuinely take on Laravel or PostgreSQL work alongside MERN projects, and I'm actively looking for freelance and full-time opportunities where I can keep building across both.

If you're working on something and think there's a fit, or you just want to see what I've built so far, my projects and contact info are here:

🔗 Portfolio: https://zahidhasantonmoy.vercel.app
🔗 GitHub: https://github.com/zahidhasantonmoy

From Web Apps to Blinking LEDs: Why Every Software Developer Should Try Hardware 🛠️

Zahid Hasan Tonmoy — Mon, 24 Aug 2026 08:55:30 +0000

Hey everyone! 👋 Zahid here.

Let us be honest—staring at code all day can become a little tiring. Most of my time is spent in the software world: writing Python tweaking a Flutter UI deploying databases on Supabase or making sure my cloud hosting on Render runs smoothly. It is fun. It is all... Virtual.

Recently I decided to step from purely software projects and started tinkering with hardware. I grabbed an ESP32, some sensors and just began playing around.. Honestly? It completely changed my view on programming.

Here’s why I think every software developer should try messing around with hardware at once:

The "Physical" Reward 💡

When you build a web app a successful compilation means a tick on your terminal or a webpage loading correctly.. When you write a few lines of code and a physical LED lights up or a robotic arm moves on your desk? That dopamine hit is just built different! It makes your code feel alive.

It Makes You Appreciate the Cloud More ☁️

Working with microcontrollers that have limited memory makes you realize how spoiled we are with cloud infrastructure. Suddenly every byte of data matters. It teaches you to write more efficient code—which ultimately makes you a better software developer.

The Ultimate Playground for AI 🤖

This is the part I'm most excited about. I have been exploring No‑Code AI agents and machine learning lately. Imagine combining an AI model with a sensor—like a smart camera that actually reacts to its environment in real time. Hardware is the bridge that brings AI out of the browser and into the world.

The Takeaway

You do not need to be an engineer to start. If you know a bit of Python you are already 90%. Grab a microcontroller a few jumper wires and build something useless but fun.

Have any of you made the jump, from software to hardware?. Have you built any cool IoT projects lately? Let us chat in the comments! 👇

Let us Connect! 🚀 If you want to talk about tech, AI or see what I am building feel free to reach out. I would love to connect!

🌐 Portfolio: zahidhasantonmoy.vercel.app

💼 LinkedIn: linkedin.com/in/zahidhasantonmoy

🐦 X (Twitter): @zahidhasan_bd

📘 Facebook: zahidhasantonmoybd