Hiring a Next.js Contractor: 12 Questions to Ask Before You Sign

Every CV says "Senior React / Next.js developer". A 30-minute call is usually all you get to find out whether that means someone who can own your frontend architecture, or someone who has shipped a few marketing sites from a template.

These are the twelve questions I'd ask if I were on the hiring side. They're grouped into technical depth, working together, and the commercial details that cause trouble later. For each one there's what a good answer sounds like and the red flag to listen for. None of them has a single right answer. You're listening for judgement: does this person explain the trade-offs, or recite one approach for everything?

Technical depth

1. How would you decide what's static, dynamic or cached on our main pages?

Rendering strategy is the decision that most affects both speed and hosting cost in a Next.js app, and it changed substantially with the App Router and Cache Components.

• —Good answer: They ask how fresh each page's data needs to be and who sees it, then decide per route: static or cached for marketing and catalog pages, dynamic for anything personalised, with cache invalidation tied to real content changes.
• —Red flag: "We'll just server-render everything", or "we'll make it a client-side SPA", with no questions about your data.

2. Where should our business logic live: Server Actions, route handlers, or a separate backend?

Next.js makes it very easy to put database calls directly in components. That's fine for a prototype and painful at scale.

• —Good answer: It depends, and they can tell you on what: Server Actions for UI mutations, a separate API (such as NestJS) when there are several clients, a complex domain or background work, and a clear boundary either way.
• —Red flag: Business rules scattered across components, or a microservices architecture proposed for a five-page product.

3. How do you measure performance, and which numbers matter?

A green Lighthouse score on a developer's laptop says little about what your users experience.

• —Good answer: Field data first: Core Web Vitals (LCP, INP, CLS) from real users via Search Console, CrUX or your analytics, then lab tools to find the cause. Bundle analysis, image and font loading, and third-party scripts are usually where the wins are.
• —Red flag: Only ever quoting a Lighthouse score, or "performance is something we optimise at the end".

4. What would you look at in your first week on our codebase?

This tells you how they reduce risk when joining an existing team, which is most of what a contractor does.

• —Good answer: Getting the app running locally, the build and deploy pipeline, error monitoring, dependency and framework versions, test coverage on the critical paths, and shipping one small real fix to learn the release process.
• —Red flag: A proposal to rewrite it before they have read it.

5. How do you handle framework upgrades, like the next Next.js major?

Next.js moves quickly. Someone who is afraid of upgrades will leave you stuck on an old version; someone careless will break production.

• —Good answer: Read the upgrade guide, run the official codemods, upgrade in a branch with the test suite and a preview deployment, and do it incrementally rather than bundling it with feature work.
• —Red flag: "If it works, don't touch it", or upgrading straight on main.

Working together

6. How do you work with our team day to day?

A contractor who disappears for two weeks and returns with a giant pull request is a liability, however good the code is.

• —Good answer: Small pull requests, code review in both directions, a few hours of overlap with your core team's time zone, and short written updates your team can read asynchronously.
• —Red flag: Vague answers about "being flexible" with no concrete rhythm.

7. How do you estimate, and what happens when an estimate turns out wrong?

Every estimate is wrong sometimes. What matters is how early you hear about it.

• —Good answer: Ranges rather than single numbers, work broken into pieces small enough to check against, and flagging slippage as soon as it's visible, together with options for cutting scope.
• —Red flag: Confident single-number estimates for large, unclear features.

8. Can you show me code you've written?

Many senior contractors work under NDAs and can't share client code. That is normal, and a good contractor will have a way around it.

• —Good answer: Open-source work, a sanitised sample, a live walk-through of how they'd structure a feature, or a short paid trial task on your codebase.
• —Red flag: Refusing to offer any evidence at all, or sharing a previous client's code without permission (they'll do the same with yours).

9. What does handover look like when the contract ends?

The best time to ask about the ending is at the beginning. You don't want critical knowledge to leave with the contractor.

• —Good answer: Documentation as they go, short architecture decision records, no parts of the system only they understand, and a deliberate handover period with your team.
• —Red flag: "I'll document everything at the end."

Commercial and legal

10. How do you invoice, and who owns the IP?

Contracting across borders is routine, but the details need to be written down. For contractors in Poland the usual model is a B2B contract with a monthly invoice; see my breakdown of the legal and tax side.

• —Good answer: A clear invoicing model (B2B invoice, with EU VAT reverse charge where it applies), and a contract that transfers copyright in the code to you, in writing, on creation or payment.
• —Red flag: No written contract, or IP transfer that isn't mentioned at all.

11. How much of your time will we actually get?

"Full-time" and "part-time" mean different things to different people.

• —Good answer: A concrete number of hours or days per week, honesty about other clients, planned time off, and a notice period that works in both directions.
• —Red flag: Promising full-time availability while clearly juggling several other projects.

12. What's the smallest paid engagement we could start with?

You wouldn't sign a year-long contract without a trial, and neither should they.

• —Good answer: A short, clearly scoped first engagement, such as a code and architecture audit or a one- or two-week sprint on a real problem, with a deliberate decision point at the end.
• —Red flag: Insisting on a long minimum commitment before you've worked together.

A quick scorecard

Before you start the search

If you're comparing rates, my guide to what developers in Poland cost has current numbers for 2026. And if you're looking for a Next.js contractor yourself, here's how I work. I'm happy to be asked every one of these questions on a first call.

Related Articles

Next.jsPerformance

Optimizing Next.js Performance at Scale: A Senior Engineer's Playbook

HiringPoland

How Much Does It Cost to Hire a Developer in Poland? A 2026 Guide