Decision guide
Next.js has become the default answer when teams need SaaS, customer portals, or marketing sites that both rank and feel fast. It’s also become a buzzword. Result: plenty of quotes for “a Next.js site” without anyone clarifying whether it’s the right model — or the right team.
Here’s how we think about the choice between in-house, freelancer, and a Next.js agency. Not as a pitch for ourselves, but as the conversation we typically have in discovery before anyone writes a line of code.
TL;DR
The key takeaways
- Hire a Next.js agency when you lack production experience in the stack, have a deadline, or need to own a product that will be operated — not just delivered.
- Stay in-house when you already have people who have shipped Next.js to production, and the product is core IP you want to keep close.
- A freelancer is often right for a sharp, bounded delivery. It gets expensive when scope drifts and nobody owns ops, SEO, and release hygiene.
- What you buy from a good agency isn’t “more hands” — it’s decisions: rendering strategy, auth, data isolation, caching, and how you release without breaking the site.
- Always ask: who owns the code, hosting, DNS, analytics, and the weekly release after go-live? If the answer is unclear, the setup is wrong.
Why Next.js is the conversation at all
Next.js combines what teams usually want at once: server-rendered HTML for SEO and first paint, React for complex UIs, and a deploy model that fits Vercel, Cloudflare, or your own Node host. That’s why both marketing sites and full SaaS products end up in the same framework.
But the framework doesn’t make the product decisions. Should the page be static, ISR, or dynamic? Where does auth live? How do you isolate tenants? What caches at the edge, and what must never be cached? Those are the questions that separate a site that feels fast for three months from one that’s still workable in three years.
A Next.js agency worth hiring talks more about those decisions than about component libraries. If the conversation starts with design systems and ends without a word on rendering, observability, or release, you’re probably buying UI — not a product.
In-house vs. a Next.js agency — in practice
In-house / own capacity
Best when the stack is already yours and you can hold pace without external dependency.
- IP and context stay inside the company
- Prioritisation follows your roadmap directly
- Needs people who have shipped Next.js to production — not just tutorials
- Ops, SEO, and incident response must also be covered in-house
- Slower start if you need to hire or train first
- Risk of “learning in production” on the first real app
Next.js agency
Best when you need pace, production defaults, and a team that has seen the failure modes before.
- Faster from decision to first preview deploy
- Defaults for auth, caching, forms, SEO, and observability come with it
- You buy decision-making — not just implementation time
- Needs a clear ownership model after go-live
- Poor fit if you only want pixel-perfect UI without product ownership
- Works best with an internal product owner who can say yes/no weekly
When to choose what — a concrete matrix
Use this when you’re stuck between “we’ll do it ourselves”, “we’ll find a freelancer”, and “we’ll hire an agency”.
Stay in-house / freelancer
You already run Next.js in production with people who have operated it
Hire a Next.js agency
In-house — use external help for peaks, not for core decisions
Stay in-house / freelancer
You need an MVP or relaunch inside a fixed horizon
Hire a Next.js agency
Agency — pace and finished defaults beat training mid-sprint
Stay in-house / freelancer
The job is a bounded landing page without auth or complex data
Hire a Next.js agency
Freelancer or in-house — keep it small
Stay in-house / freelancer
You’re building multi-tenant SaaS, a customer portal, or something with payments
Hire a Next.js agency
Agency or very strong in-house — mistakes here are expensive to unwind
Stay in-house / freelancer
SEO, Core Web Vitals, and preview deploys are part of the success criteria
Hire a Next.js agency
An agency that builds for crawl and performance from day one — not “we’ll fix SEO later”
Stay in-house / freelancer
You want to own the code 100% and be able to switch vendors
Hire a Next.js agency
Either model can — require repo, CI, and infra in your accounts from the start
“The expensive part is rarely the hours. It’s discovering too late that rendering, auth, or the data model was chosen wrong.”
What a good Next.js agency actually delivers
A serious engagement doesn’t start with Figma-to-code. It starts with scope: which pages are public, which are authenticated, which data may be cached, and what “done” means for the first release. Without that you end up with a beautiful UI on top of an unclear backend.
Then come stack defaults. For most business products that means Postgres, server-side auth, typed API boundaries, preview environments on every pull request, and a deploy pipeline you can understand. Next.js is the framework — the rest is what makes the product operable.
Finally: handover. You should be able to point at the repo, hosting account, domain, analytics, and the person (internal or external) who picks up the phone when something fails on a Friday. If the agency “hosts everything for you” without you holding the keys, you bought a dependency — not a product.
Questions you should ask a Next.js agency
If the answers are unclear, that’s a signal — no matter how polished the portfolio looks.
- Who owns the GitHub repo, Vercel/Cloudflare account, DNS, and database after go-live?
- How do you choose between static, ISR, and dynamic rendering for our page types?
- How do you handle auth, roles, and (if relevant) multi-tenant isolation?
- Do we get a preview URL on every pull request, and who approves releases?
- What’s your plan for Core Web Vitals, sitemap, canonicals, and hreflang?
- What do the first 90 days of operations look like — who monitors, and how do we escalate?
- Can we continue in-house later without rewriting half the site?
A sensible way to start the collaboration
Whether you choose us or someone else — this sequence saves weeks.
- 01
Discovery on the problem — not the UI
Clarify users, auth, data, SEO requirements, and what “done” is for v1. Prefer flows over mockups in week one.
- 02
Choose rendering and hosting before the component library
Decide what’s static, what’s dynamic, and where it deploys. UI kits can be swapped. A wrong data model cannot.
- 03
Get a first preview early
Get a deployed URL up quickly — ideally within the first iterations — so you react to something real, not slides.
- 04
Write ownership into the agreement
Repo, environments, secrets, and domain in your accounts. The agency works inside that. That makes exit and in-house takeover possible.
- 05
Plan operations before launch
Agree monitoring, backups, who fixes incidents, and how you ship changes after go-live. Launch without ops is only half the job.
Questions we get over and over
How is a Next.js agency different from a classic web agency?
A classic web agency often optimises for design delivery and CMS pages. A Next.js agency (that means it) optimises for app-like products: server rendering, auth, APIs, preview environments, and performance under real traffic. You should hear words like ISR, edge caching, migrations, and observability — not only “responsive design” and “WordPress theme”.
Can we start with an agency and take over in-house later?
Yes — if the agreement is built for it. Require that code, CI, hosting, and documentation live with you from day one, and that the stack is common enough for an internal developer to continue. We work that way on purpose: the goal is that you can take over, not that you’re locked in.
Is Next.js only for marketing sites?
No. Next.js is used for marketing sites, customer portals, and full SaaS products. The difference is rendering strategy and backend weight — not the framework. A marketing site can be almost static; a SaaS has auth, roles, and frequent data updates. Same tool, different defaults.
How long is a typical Next.js MVP?
A focused MVP typically lands in the 8–14 week range, depending on auth, integrations, and how sharp the scope is. That’s process timing — not a promise about your specific project. What blows the timeline is almost always unclear requirements mid-way, not Next.js itself.
Do we have to choose Vercel if we choose Next.js?
No, but it’s often the lowest friction for teams that want preview deploys and edge without building the platform themselves. Cloudflare, containers, and classic Node hosting are also fine. The choice should follow your ops requirements, compliance, and existing cloud — not dogma.
If you’re mid-decision
Have a no-strings conversation about setup — before you pick a team.
Happy to help clarify whether in-house, freelancer, or agency is right for your Next.js project. You’ll get an honest take, even if the answer is to wait or build it yourselves.