What I Learned Shipping 3 Full-Stack MERN Projects as a Solo Developer

Mohammad Haroon — Fri, 03 Jul 2026 16:14:59 +0000

A while back I sat down and counted how many full projects I'd actually shipped, start to finish, on my own. Not tutorials. Not clones. Real products with real users testing them. The number was three, and each one taught me something the last one didn't.

I'm Muhammad Haroon, a full-stack developer working mostly in the MERN stack out of Bahawalpur, Pakistan. This isn't a "10 tips for React" listicle. It's what actually happened while building a SaaS tool, an AI meeting app, and a maritime job platform, including the parts that broke and the decisions I'd make differently now.

Project 1: A multi-tenant SaaS taught me that architecture decisions compound

The first big one was ProjectSphere, a project management tool built to support multiple organizations on a single codebase. Simple idea. Deceptively hard execution.

The mistake I made early was treating "multi-tenant" as a database problem only. I figured if I scoped every query by organizationId, I was done. I was not done.

What I actually needed to think through:

Data isolation: one bad query without a tenant filter and you've leaked another company's data. I ended up writing a Mongoose middleware layer that injected the tenant scope automatically instead of trusting every controller to remember it.
Role-based access inside each tenant: an admin in Org A shouldn't accidentally get admin rights in Org B just because the JWT payload wasn't checked properly.
Onboarding flow: every new org needs default roles, default project templates, and a clean first-run experience, or your product feels half-built even when the core features work fine.

The lesson that stuck with me: in multi-tenant systems, the boring stuff (data scoping, permission checks, seed data for new tenants) is the actual product. The flashy features are what people see in the demo. The boring stuff is what keeps you out of a very bad support ticket six months later.

Project 2: Real-time audio taught me to respect the network

Next was Meeting AI, a meeting platform with live transcription and AI-generated notes. React 19 on the frontend, Express 5 on the backend, Supabase for storage and auth, Agora RTC for the real-time audio layer, and Groq's Whisper implementation for transcription.

This project humbled me. WebRTC and real-time audio are not "just another API integration." The moment you introduce live audio streams, you're dealing with:

Network jitter and packet loss that behaves completely differently on a stable office wifi versus someone's mobile data on a bus
Reconnection logic, because a dropped connection mid-meeting is a support nightmare if you haven't planned for it
Latency between when someone speaks and when the transcription shows up, which affects how "live" the product actually feels

I originally tried handling reconnection with a naive retry loop. It worked in testing on my own laptop and fell apart the first time a real user tested it on a spotty connection. I had to rebuild that layer with proper state management for connection status, so the UI could tell the user "reconnecting" instead of just silently failing.

The other piece worth mentioning is multi-organization workspace support with role-based access control, which I built into this project too. If you're adding RBAC to a real-time product, test your permission checks against live sessions, not just static API calls. Permissions that work fine on a REST endpoint can behave unexpectedly once a session is already active and a user's role changes mid-call.

Project 3: A maritime job platform taught me that "modules" beat "monoliths" for client work

MaritimeLink was a job platform for the maritime industry, built with React, Tailwind, and REST APIs, with modules for KYC verification, job applications, training courses, and an admin panel.

This one was closer to freelance client work than a personal project, and it changed how I structure things now. Instead of building one large application, I broke it into modules that could be developed, tested, and even disabled independently:

/modules
  /kyc
  /job-applications
  /courses
  /admin-panel

Each module had its own routes, its own state slice, and its own API layer. When the client wanted to change how KYC verification worked, I didn't have to touch the job application logic at all. When they asked for a new admin feature, it slotted into the admin module without a ripple effect through the rest of the app.

For anyone doing freelance or client-based development, this is probably the single most useful pattern I've adopted. Clients change their minds. Scope shifts. A modular structure means those changes cost you hours instead of days.

The pattern across all three

Looking back at these projects together, a few things kept repeating regardless of what the app actually did:

The unglamorous 20% (auth, permissions, error states, reconnection logic) takes 80% of the real engineering effort. Budget your time accordingly, especially if you're quoting freelance work by the hour.
Test on bad conditions, not good ones. Slow networks, wrong permissions, empty states. Your happy path will always work. Your app is judged on what happens when things aren't happy.
Modular beats monolithic once a second developer, a second client, or a second organization enters the picture. You don't need to over-engineer a personal project, but the moment real users or real clients show up, structure pays for itself fast.

What's next

I'm currently doing full-stack work with the MERN stack as part of an internship, alongside freelance projects on the side, mostly React, Node, and WordPress builds for small businesses. If you're working on something similar or you've hit these same walls with real-time apps or multi-tenant systems, I'd genuinely like to hear how you solved it. That's usually how I learn the most, from someone else's war story about the bug that took them three days to find.