Next.js Agency vs Freelancer: How to Scope a Real Product Build

Next.js agency vs freelancer is a staffing question. The useful question is how you scope a real product build: auth, CMS, SEO preservation, environments, and who owns the repo after launch. Comparing 'agencies have process' to 'freelancers are cheaper' is how you get a beautiful Next.js marketing site with a login button that 404s.

I build this stack for a living: Next.js with Sanity or Supabase, sometimes both. I work independently through ZedNova Studios. I still tell buyers to pick the operator who can write the scope, not the logo that looks like a product studio on Dribbble. This is not a Framer vs Webflow argument. If you are still choosing a visual builder, you are in a different conversation.

If the live site is Framer and you are wondering whether to stay, start with when to hire a Framer developer versus moving to Next.js. Come back here once the decision is 'we are building an application-shaped site, not another canvas.'

What you are actually buying

A Next.js build is a software project that happens to render a website. You are buying routing, data fetching, preview, forms, auth if you need it, and a content model. You are also buying the boring production layer: env vars, previews, redirects, and a sitemap that does not list 500s.

Metadata in the App Router is a good example of why vague scope fails. Titles, canonicals, Open Graph, and robots have to be implemented per template, often from CMS fields, with fallbacks. If the agency treats this as 'SEO later,' you will launch with duplicate titles and a sitemap that includes preview routes. The current Next.js metadata docs are the implementation baseline, not a plugin you add after launch.

Agencies can staff that with a PM, a designer, and two developers. Freelancers can staff it with one person who actually understands the coupling. Both models fail when the SOW says 'Next.js website' and never names auth, CMS, or the old URL list.

• Marketing pages that must keep existing URLs and metadata.
• A CMS editors can preview without running the app locally.
• Auth, roles, and the first admin path if this is a product.
• Analytics and booking or checkout that still fire after launch.
• A repo, hosting account, and CMS project under your company.

If ownership is not in the contract, you rented a black box with a nicer Lighthouse screenshot.

Scope auth like a product, not like a plugin

Auth is where 'simple Next.js sites' become products. Email magic links, OAuth, invites, and admin impersonation each change the data model. Supabase Auth, Clerk, Auth.js, or a custom stack: pick one, write the user stories, and name who supports it at 2am.

Read the provider docs before you accept a two-line estimate. Supabase Auth is explicit about sessions and policies. If the freelancer cannot explain row-level security in one paragraph, do not let them 'add login later.'

An agency will sometimes hide auth in a 'phase 2' so the marketing site can launch. That is valid if you say it out loud. It is not valid if the sales deck implied an app and the contract delivered a brochure.

Write the auth stories as user outcomes, not as library names. 'Invite a teammate and they land in the right workspace' is a story. 'Add Clerk' is a shopping list. Stories force edge cases: expired invites, someone who already has an account, an admin who must disable a seat without deleting content. Freelancers who have shipped this will estimate those. Agencies that have not will smile and put it in a backlog named 'nice to have.'

CMS: Sanity (or similar) as a product surface

Headless CMS work is not 'install a blog.' You are designing document types, references, validation, and a Studio that a marketer can survive. Preview, drafts, and scheduled publish are part of the build, not a nice-to-have.

Sanity's own content modeling docs are the right starting point. If the proposal has no schema sketch, you are paying for pages, not a system.

What to demand in the CMS slice

• Document types that match real content, with required SEO fields.
• Draft/preview that uses the production host, not a secret tunnel only the agency can open.
• Roles so contractors cannot publish, or can, on purpose.
• A portable content format you can export. Do not trap copy in a one-off component tree.

Preview is the marketing-team test. If editors must ask a developer to run the app locally, you did not buy a CMS. You bought a developer bottleneck with extra JSON. Next.js preview or draft routes should open in a browser the marketer already uses, with a clear 'this is draft' banner so they do not screenshot unpublished pricing.

SEO preservation is a scope line, not a hope

Custom Next.js is where teams quietly drop rankings because metadata lived in Webflow fields and nobody ported it. Canonicals, titles, Open Graph, redirects, robots, and sitemap generation belong in the first milestone, not a 'SEO pass' after the party.

JavaScript SEO is in scope too. If important copy only appears after client fetch, you will look fine in a logged-in browser and thin to Googlebot. The builder should know the difference between server-rendered HTML and a loading skeleton. Google's JavaScript SEO basics are the reference, not a Lighthouse marketing slide.

If this build replaces Webflow, WordPress, or Wix, treat it as a platform move. The decision of whether to leave is website replatforming. The SOW still needs a URL inventory and one-hop 301s, the same as any migration.

Google's site move documentation is the rulebook. 'Next.js will handle it' is not a redirect map.

What a weak Next.js proposal looks like

It sells 'Next.js 15, App Router, blazing fast' and never lists redirects. It includes a design system and zero schema sketch. It promises a blog in a week and auth in a later phase that has no budget. It uses stock screenshots of a dashboard you will not get.

It also hides hosting. 'We deploy to Vercel' without saying whose team, whose invoice, and who can roll back. Preview deployments that only work on the agency login are a tell. So is a CMS the marketers cannot open without a call.

A strong proposal is almost boring. Routes. Document types. Auth stories. Redirect owner. Analytics. Environments. Acceptance tests for metadata on one money URL. That document is how you compare an agency to a freelancer without getting hypnotized by case-study lighting.

Agency vs freelancer: pick for the work shape

Hire an agency when you need parallel design, motion, and engineering in the same month, and you have someone internal who can still own the product decisions. Hire a freelancer or small studio when the risk is coupling: auth plus CMS plus SEO on one domain, and you cannot afford translation loss between three vendors.

Agencies are better at covering vacation and at running a design critique. They are worse when the PM has never shipped App Router metadata. Freelancers are better at integrity. They are worse when you need a brand team and a developer in the same week and they are one person.

Hybrid models exist: a freelancer who brings a designer, an agency that lets you talk to the engineer. Interview the person who will write the schema and the redirects, not only the person who runs the kickoff. If you cannot get that person on a call, you are buying account management.

Ownership: repo, hosting, CMS, DNS

Your GitHub or GitLab org. Your Vercel/Netlify/hosting team. Your Sanity project or Supabase org. Your domain registrar. Agency-owned repos are the Next.js version of a Webflow workspace hostage situation. Put transfer language in the contract before kickoff.

1. Company-owned Git remote on day one, even if they push.
2. Environment variables documented, not living in one laptop.
3. Preview URLs that your team can open without a VPN ritual.
4. A written runbook for deploy, rollback, and CMS restore.

DNS and email are part of ownership even when they feel off-topic. A Next.js cutover that breaks MX records or the calendar embed is a product incident, not a 'marketing issue.' Put the domain checklist in the same SOW as the repo. The freelancer who has done this will mention it. The agency PM who has not will discover it on Friday night.

A scope sheet you can send either party

Paste this into the RFP. If they skip lines, they are bidding a brochure.

Score the replies in a table: auth, CMS preview, SEO map, ownership, environments. Ignore the mood film. The operator who can fill those cells will beat the studio that only talks about 'craft.' If both can fill them, pick the one you can still reach after launch without a new statement of work.

• URL inventory and redirect owner.
• Metadata component map (static vs CMS-driven).
• Auth provider, roles, and admin path (or an explicit 'no auth in v1').
• CMS schema sketch and preview method.
• Forms, bookings, and where submissions go.
• Analytics IDs and consent behavior.
• Who owns Git, hosting, CMS, and DNS.
• What 'done' means: production deploy plus a 14-day bug window, not a Figma export.

If the underlying problem is that strategy and build were sold as two different companies, read why a digital product consultant has to stay connected to build. Scoping Next.js without that connection is how you buy two invoices and one stalled launch.

I will read a Next.js proposal and tell you which lines are missing. Send the current site, the target stack, and whether login is in v1. That is a better first call than a portfolio walkthrough.

If the proposal cannot name those three things, it is not a product build yet. Do not sign it because the homepage mock looks expensive.