Hiring a Next.js developer: a founder's guide

Hiring a Next.js developer in 2026 is harder than it should be, mostly because the talent pool is huge and varied — a ten-year veteran charging €150/hr looks the same as a six-month bootcamp graduate charging €15/hr until you read their portfolio carefully. This post is the playbook I'd give a founder before they spend a dollar.

I've been on both sides — hired into projects, and watched founders hire other Next.js devs (sometimes well, sometimes badly). The patterns are consistent enough to write down.

Why specifically Next.js

If you're hiring for a "Next.js developer," you've probably already decided that Next.js is the right framework for what you're building. Quick sanity check: it usually is, but not always.

Next.js is the right choice when:

• You're building a web app that needs server-rendered pages for SEO
• You want a single framework for both frontend and API layer
• You're hiring for the long term — Next.js has the largest hireable pool of any React framework
• You want to deploy on Vercel (or any major cloud) without custom infra work

Next.js is not the right choice when:

• Your product is mobile-first (use Expo + React Native instead)
• You're building a pure marketing site with no app logic (Astro is lighter)
• You need extreme low-latency edge computation (Cloudflare Workers might fit better)
• You have a team that knows Vue/Svelte/SolidJS and shipping speed matters more than long-term hireability

If Next.js is right, here's how to hire for it.

Where to find Next.js developers

Roughly in order of signal-quality:

Personal referrals. A working Next.js dev your trusted founder friend has shipped with. Almost always the best signal. Use it if you have it.

Vercel community / Next.js Discord. Devs who participate in the Vercel ecosystem are usually current on the latest patterns. The signal-to-noise is high; ratings and active project history are visible.

Cal.com / Twenty / open-source Next.js project contributors. GitHub commits in major Next.js OSS projects are a public, verifiable track record. Search the contributor lists.

Twitter / X build-in-public devs. Someone who's shipping Next.js projects publicly under their own name is committing reputational capital to their work. The "shipping in public" signal is strong.

Toptal / Lemon.io / specialized agencies. Vetted, expensive, reliable. The vetting filters out junior devs but also filters out the most senior ones (who don't need a marketplace).

Fiverr Pro / Upwork Top Rated. This is where I work. The platforms have mediocre filtering but a strong portfolio + reviews can carry the signal. Look for "Level 2" or "Top Rated" badges + 4.9+ ratings + visible portfolio.

LinkedIn / general job boards. Lowest signal. Fine for full-time hires, terrible for short-term project work.

Generic dev directories. Avoid. The signal-to-noise is brutal.

What to look for in a portfolio

This is where most founders go wrong. They look at visual quality of past work and assume that translates to engineering quality. It often doesn't.

Three signals that matter more:

1. Shipped products, not just designs

A portfolio full of Figma screenshots is a designer's portfolio. A portfolio full of live URLs is a developer's portfolio. Click the links. Are they real, working products? Or are they static demos?

2. Variety in problem-shape

Five SaaS dashboards mean the dev has shipped one type of project five times. One SaaS, one marketplace, one mobile app, one AI tool means the dev has solved different problems and adapted. The second is more useful for an MVP where you don't know yet which problems will dominate.

3. Public artifacts

Blog posts, GitHub commits, conference talks, open-source contributions. Even one real artifact is enough — it tells you the dev can communicate, not just code. Pure-resume devs without any public work are higher-risk hires.

The interview that actually works

Skip the algorithm puzzles. Skip the "build a TypeScript type that..." trick questions. Real Next.js work is product engineering, not algorithm engineering. Three questions that filter ruthlessly:

"Walk me through the architecture of your most recent shipped project"

You're listening for clarity, not specific tools. Can they explain what they built and why? Do they know which tradeoffs they made? Can they say "I'd do X differently next time"?

A senior dev's answer sounds like a story. A junior dev's answer sounds like a list of tools they used. A bad-fit dev's answer sounds like marketing copy.

"What's the hardest bug you've shipped in the last six months?"

This is the question I borrow from Patrick McKenzie. If they don't have one, either they're not shipping enough, or they're hiding the bugs. Both are problems.

You're listening for: did they understand the bug? How did they find it? Did they ship a real fix or a workaround? What did they learn?

"Build me [tiny thing] in front of me, narrating what you do"

A 30-minute pair-programming session. I usually ask devs to build a working email signup form with Supabase auth, deployed to Vercel, in 30 minutes. It's a real task. Anyone with real Next.js experience does it in 15 minutes. People who haven't actually shipped Next.js spend 30 minutes fighting npm install.

This single test sorts hires faster than any other interview format I've used.

Red flags to walk away from

Quotes you a price before scoping. "I can build a SaaS for €5K" without asking what the SaaS does is a sign of someone who'll bill you for surprises later.

No live preview URL during the build. This is 2026. Vercel preview URLs are free. A dev who can't show you progress live every day is hiding something.

Refuses to use git, GitHub, or a version control workflow you can audit. Massive red flag. There's no legitimate reason to skip this in 2026.

Insists you can only see the code at the end. You should have read access to the repo from day one. Not seeing your own code in progress is how scams happen.

"I'll handle hosting / I'll keep it on my server." A shipped product belongs on infrastructure you own, with credentials you control. Anything else is hostage situation potential.

No portfolio of working products. Not "I built things at a previous job that I can't show you" — that's fine. But "I've never built a complete product I can show you" is a junior signal, and that's a fair price point but be calibrated.

Asks for full payment upfront with no milestones. 50% upfront / 50% on delivery is normal. 100% upfront with no escrow is a setup.

Doesn't ask questions during the kickoff call. A dev who has no questions doesn't understand the project yet. Real builders ask 10-30 questions in the first hour.

What to pay

Real ranges for solo Next.js developers in 2026, by experience:

| Experience | Hourly | Project (MVP) | Project (Full SaaS) | |---|---|---|---| | Junior (<2 yrs) | €25–60/hr | €2,000–5,000 | not recommended | | Mid (2-5 yrs) | €60–120/hr | €5,000–15,000 | €15,000–40,000 | | Senior (5+ yrs) | €100–200/hr | €8,000–25,000 | €25,000–80,000 | | Specialist (rare skill) | €150–300/hr | €15,000–50,000 | €40,000–150,000 |

These are global ranges. Eastern European devs at the same skill level often charge 60-70% of the Western European rate. US-based devs often charge 130-150%. Quality varies more by individual than by geography — but the floor (very-junior) and ceiling (FAANG-tier engineer moonlighting) are wider in some markets than others.

The contract that protects both sides

You don't need a 40-page master services agreement for a €5K project. You do need a few clauses in writing:

Scope. What's being built, in plain language. List the screens, the user flows, the integrations. If something isn't on the list, it's not in scope.

Deliverables. What you receive at the end. Source code in your GitHub. Deployment instructions. Loom walkthrough. Domain pointed at the live deploy.

Payment terms. Total amount. When each payment is due. What triggers each payment (delivery, demo, milestone).

IP ownership. You own the code on final payment. Standard. Don't accept anything else.

Revisions / fixes. Most builders include 1-2 weeks of post-launch fixes free. Get this in writing so it's not a "well that's extra" surprise.

Termination. What happens if either side wants out. Usually: you pay for work completed to date, you get the code as-is, both sides walk.

I send my clients a 1-page agreement with all of these. It's not a legal weapon — it's a memory aid that prevents drift in week three.

Scoping the project

This is the part founders skip and then regret.

Before you talk to a builder, write down:

1. The user. Who uses this product? What do they currently do instead?
2. The core action. What's the one thing the product enables that's currently hard?
3. The MVP screens. Three to five screens that complete the core action. Sketch them in Figma or on paper.
4. The non-goals. What you're explicitly not building. Important: this saves both sides.
5. The success metric. How will you know if it's working after launch?

Bring this to the builder. Their first job is to react to it: "I'd cut X, expand Y, push back on Z." A builder who just nods and says "looks good, send the contract" isn't engaging with the product, just the engagement.

Working together

Once you've hired:

Communicate daily. A short Slack/email update from the builder every weekday. "Today I shipped X. Tomorrow I'll work on Y. Blocked on: Z." Five minutes of writing, prevents 10 hours of confusion.

Live preview from day one. Even if it's just a "Hello World" Vercel deploy. Seeing the URL changes how the project feels.

Weekly demos. Even on a one-week MVP, a 30-minute demo halfway through prevents a 100% spec mismatch at the end.

Don't add scope mid-build. Write down every "oh and also" idea. They become v1.1, after launch. The MVP scope is locked at kickoff.

Pay on time. Best signal of a good client. Builders remember.

When to bring it in-house

A solo Next.js builder is usually the right choice for the first 6-18 months of a product. After that, you typically want to bring engineering in-house — not because the builder is failing, but because the product needs continuous attention that fits worse and worse with project-shaped work.

Signs you're ready for in-house:

• The codebase has >50K lines and you're shipping features weekly
• You have a roadmap that extends 6+ months
• You can afford a salary (probably €60K-150K depending on location)
• The product is making money or has funding to do so

When you hire your first in-house engineer, ask the freelancer to do a structured handoff: a Loom architecture walkthrough, a "where the bodies are buried" doc, a one-month overlap for questions. A good freelancer expects this. A bad one resists.

What I won't do (and what to ask any builder)

I won't take on projects under €1,500 — the overhead of starting a project is fixed regardless of size, and below that price I'd be losing money to take it. If your project is smaller than that, the right move is a no-code tool, not a developer.

I won't take on projects where the founder hasn't done step 1 of the scoping above. "I have an idea, what should I build?" is a consulting engagement, not a build. I'm happy to do paid product strategy, but not bundled into a fixed-price build.

Ask any builder these questions before signing:

• "What would cause this project to go over budget?"
• "What's the riskiest part of this build?"
• "What would you push back on in my spec?"
• "Have you shipped something similar before? Can I see it?"

The answers tell you what kind of partner you're getting.

---

If you're scoping a Next.js project, tell me about it — I'll send back a quote and a build plan within 48 hours, or honest pushback if it's not the right fit. See recent case studies and pricing.