I'm a MERN stack developer, so I'm writing this from the other side of the table. I've seen how clients find developers, what they check, and more often what they forget to check. The good news is that most bad hires are avoidable with a few hours of homework before the first call.
Here's the checklist I'd use if I were hiring a MERN stack developer myself.
What a MERN stack developer actually does
MERN stands for the four pieces of a JavaScript web application:
- MongoDB, the database, which stores data as flexible JSON-like documents.
- Express, the web framework that defines your API routes on the server.
- React, the library for building the interface people click on.
- Node.js, the runtime that runs JavaScript on the server.
A MERN stack developer can build all four layers, which means one person can take a product from the database to the button. That's the main reason to hire one: fewer handoffs, and nobody saying "that's a back-end problem".
Is MERN the right stack for your project?
MERN is a strong choice for:
- SaaS products and dashboards behind a login.
- Marketplaces, booking systems and internal tools.
- Apps with real-time features such as chat, notifications or live updates.
It's not always the best choice:
- Public pages that must rank on Google. A plain React front end renders in the browser. Use Next.js for those pages, which keeps the same JavaScript skills but renders on the server. I explain the difference on my Next.js development page.
- Content sites and simple stores. A well-built WordPress site is often faster to launch and easier for your team to edit.
- Heavily relational data, such as complex accounting, may suit a relational database better than MongoDB.
A good developer will tell you when your project doesn't need their favorite stack. Treat that as a point in their favor.
Freelancer, agency or full-time hire
- A freelancer suits a defined project or a first version. You get one accountable person and usually a faster start. The risk is availability, so ask how many projects they run at once.
- An agency suits work that needs several specialists in parallel. You pay more for coordination, and the person who sold you the project may not be the person writing the code.
- A full-time hire suits a product you'll develop for years. The hiring process is slower, but knowledge stays in the company.
Many teams start with a freelancer to ship the first version, then hire full-time once the product has proven itself.
How to read a developer's portfolio
A portfolio is only useful if you check it properly:
- Open the live sites. Are they still up? Do they load quickly on your phone? A broken project in a portfolio is worth asking about.
- Ask what the developer actually did. "Worked on" can mean anything. On my own projects page I spell it out per project. For example, on NetworkUstad my work was SEO, not the design, and the page says so.
- Look for something close to your project. If you're building a SaaS product, a time tracker like Staffvertex tells you more than ten landing pages.
- Check the code if you can. A GitHub profile shows how someone names things, structures a project and writes commit messages. Client code is often private, so personal projects count too.
Questions that separate good from good-looking
You don't need to be technical to ask these. Listen for specific, concrete answers rather than buzzwords.
- "How would you design the database for my app?" A good answer starts with how the data will be read, not just what fields exist, and mentions indexes.
- "How do you handle logins and passwords?" Listen for hashed passwords, secure sessions or tokens, and role checks on the server, not only in the interface.
- "What happens when the API gets bad input?" Validation, clear error messages and no crashes.
- "How will you deploy it, and how do we release updates?" There should be a plan, not "we'll see".
- "What would you build first, and what would you leave out?" Good developers cut scope to ship sooner.
- "How will I know how the project is going?" You want a rhythm: weekly updates, a preview link, a shared task board.
A useful test
Ask them to explain a past project's architecture in plain English. If they can make it clear to you, they'll be able to explain problems to you during your project too.
Run a small paid trial
Before committing to a large project, pay for one small, real piece of work that takes a few days: a single feature, an API endpoint with its screen, or a bug fix in your existing code. You'll learn more about code quality, communication and reliability from that than from any interview. Pay for it. Good developers rarely do unpaid test projects.
Working with a developer in Pakistan
Pakistan has a large pool of experienced JavaScript developers, and many work with clients in the US, UK, Europe and the Gulf. I'm based in Islamabad and work with clients remotely over Zoom, Trello and GitHub. A few practical points:
- Time zones. Pakistan Standard Time is UTC+5. Afternoons in Pakistan overlap with mornings in the UK and Europe, and Pakistani evenings overlap with mornings on the US East Coast. Agree on a daily window when both sides are online.
- Communication. Written updates matter more when you're not in the same room. Ask for a short summary at the end of each week: what shipped, what's next, what's blocked.
- Payments. Freelance platforms such as Upwork handle payment and escrow. For direct contracts, services like Payoneer and Wise are widely used.
Contracts, milestones and handover
- Write down the scope as a list of features and pages, and agree what "done" means for each.
- Split payment into milestones tied to working software you can click through.
- Make sure the code lives in a repository you own, from the first day.
- Agree who owns hosting, domains and third-party accounts. They should be in your name.
- Ask for a handover: how to run the project, how to deploy, and where the important settings live.
- Agree on support after launch, because there will be bugs to fix.
Red flags
- They agree to everything and never ask a question about your business.
- They want full payment up front for a large project.
- Portfolio links are broken, or they can't say what their part was.
- They want to host your code in their own account with no access for you.
- Estimates come back within minutes, before they've understood the scope.
If you're looking for a MERN stack developer for a SaaS product, marketplace or internal tool, here's how I work on MERN stack projects, and you can read about my background. When you're ready, tell me about the project. I'll tell you honestly whether MERN is the right fit.
Originally published on my portfolio. I'm Osama Khattak, a MERN stack and Next.js developer in Islamabad. See my work at osama-s-porfolio-beige.vercel.app.
Top comments (0)