Why Pylonworks Builds on Next.js for Nearly Every Client Project
Why Pylonworks defaults to Next.js: ISR, edge routing, the Vercel deploy story, TypeScript fit, and the one project type where it is the wrong call.
Pylonworks builds on Next.js because it folds rendering, routing, build tooling, and deploy into one system a small team can ship fast and a client can run cheaply. One framework covers marketing sites, dashboards, and content pages without gluing three separate tools together.
A client site I rebuilt last quarter went from a 4.1s largest-contentful-paint on a hand-rolled Express app to 0.8s on Next.js with incremental static regeneration, and the deploy pipeline went from a 12-minute SSH-and-pray ritual to a 90-second push to Vercel. That gap is the short version of why we default to it. It costs us the least to ship and costs the client the least to run.
I have shipped enough stacks to be suspicious of monoculture. So this is not a love letter. It is the actual accounting: what Next.js saves, what it costs, and the one case where I reach for something else.
What makes Next.js the default at Pylonworks?
Next.js is the default because it collapses four separate decisions (rendering strategy, routing, build tooling, and deploy target) into one coherent system that a small team can run without a dedicated ops person. For a studio shipping client sites on fixed budgets, that consolidation is the whole game.
Most client work is the same shape: a marketing site, a dashboard, a content-heavy product page, sometimes a light API layer. Next.js handles all of those in one codebase with one mental model. I am not gluing a static site generator to a separate API to a separate CDN config. The Next.js App Router lets me pick static, server-rendered, or client-rendered per route, in the same project, without a rewrite. That per-route flexibility is rare and it is the thing I would miss most.
The studio's own work runs on this stack too. You can see the live result at https://pylonworks.com, which is a Next.js build on Vercel.
How does ISR cut hosting costs for content sites?
Incremental static regeneration serves pages as static files and rebuilds them in the background on a timer or on demand, so a content site gets static-file speed without a full redeploy every time the content changes. That removes the classic tradeoff between fast static sites and fresh dynamic ones.
Here is the pattern I use on most marketing and blog builds:
// app/blog/[slug]/page.tsx
export const revalidate = 3600; // rebuild this page at most once an hour
export async function generateStaticParams() {
const posts = await getPublishedSlugs();
return posts.map((slug) => ({ slug }));
}
The practical effect: a 200-page content site serves almost entirely from cache. Origin compute fires only when a page is stale and someone requests it. On one client blog that move dropped serverless function invocations by roughly 95% month over month, because the same handful of hot pages stopped re-rendering on every hit. Static-file response times sit in the tens of milliseconds. The client pays for a fraction of the compute they would burn on full server-side rendering.
The mistake I made early was rendering everything server-side because it was easy. ISR is the same developer experience with a tenth of the bill. If a page does not need per-request data, it should not pay for per-request compute.
What does edge routing actually buy you?
Edge routing runs lightweight code (redirects, auth checks, A/B splits, geolocation) at the CDN node closest to the user instead of at a single origin server, which cuts the round trip from hundreds of milliseconds to tens. It matters most for the work that happens before your page even renders.
Middleware is where this shows up in real projects. A request hits an edge node, middleware checks a session cookie or a country header, and either rewrites, redirects, or continues, all before the request travels to your origin. For a US-origin app serving a user in Sydney, doing an auth redirect at the edge instead of the origin saves a transpacific round trip that can run 200ms or more.
I keep middleware thin on purpose. It runs on every matched request, so a slow check there taxes the whole site. Auth gating, locale redirects, and bot filtering belong there. Database queries do not.
Why does the TypeScript story matter for client handoffs?
Next.js ships built-in TypeScript support with typed routes, typed API handlers, and zero config to start, which means the code we hand off is self-documenting and survives the next developer who touches it. For a studio that does not maintain every site forever, that durability is a feature we sell.
We run strict: true and derive types from Zod schemas at the boundaries, so the data shape a page expects is enforced at build time. When a client's in-house developer picks up the project a year later, the types tell them what every function wants. That is the difference between a handoff and an abandonment. The build fails loudly on a type mismatch instead of shipping a runtime error to production.
How does the Vercel deploy story compare to self-hosting?
Deploying Next.js to Vercel is a git push that produces a preview URL on every branch and a production deploy on merge, with no server to patch, scale, or wake up at 3am. Self-hosting is cheaper in raw dollars and more expensive in hours, and for most client budgets the hours lose.
Here is the honest tradeoff I weigh on every project:
| Factor | Vercel | Self-host (VPS / container) |
|---|---|---|
| Time to first deploy | Minutes | Hours to days |
| Preview deploys per PR | Automatic | Build it yourself |
| Base cost | Free tier, then $20/mo per seat (Pro) | ~$5-40/mo VPS, plus your time |
| Scaling | Automatic | Manual or configured |
| Ops burden | Near zero | Patching, monitoring, on-call |
| Egress / overage risk | Metered, can spike | Predictable, capped |
Vercel's Pro plan runs $20 per month per seat as of mid-2026, with usage-based pricing on top for bandwidth and function execution (see Vercel's pricing page for current figures). For a typical brochure or content site that bill stays small. For a high-traffic app with heavy server rendering, metered overages can climb, and that is exactly when I run the self-host math instead. Next.js itself is not locked to Vercel. It runs in a Node server or a Docker container anywhere, which means the framework choice and the host choice stay separate decisions.
When is Next.js the wrong choice?
Next.js is the wrong choice when the project is a pure static brochure with no dynamic data, no auth, and no growth path, because then it is overhead you maintain for nothing. The framework earns its weight through rendering flexibility. If a project will never use that flexibility, you are carrying a React runtime and a build pipeline to render what could be flat HTML.
The cases where I reach for something lighter:
- A five-page static marketing site that will not change much. Astro or plain HTML ships less JavaScript to the browser and is faster to build. I have moved a couple of these off Next.js and the Lighthouse scores went up.
- A heavy real-time app that is mostly one interactive surface. A single-page app with a dedicated backend can be a cleaner fit than fighting server components for a canvas-style UI.
- A backend-only service. If there is no meaningful frontend, Next.js is the wrong tool. Use a real API framework.
Being willing to say no to your own default is what keeps it a decision instead of a habit. Most client work genuinely fits the Next.js shape. When it does not, I say so before the contract is signed.
FAQ
Is Next.js free to use?
Yes. Next.js is an open-source framework released by Vercel under the MIT license, so the framework itself costs nothing. You pay only for hosting, whether that is Vercel's metered plans or a server you run yourself.
Do I have to host on Vercel to use Next.js?
No. Next.js runs as a standard Node application and ships in a Docker container or on any VPS. Vercel gives you the smoothest deploy experience and the tightest integration, but the framework and the host are separate choices you can make independently.
What is ISR in Next.js?
ISR (incremental static regeneration) is a rendering mode that serves pages as cached static files and rebuilds individual pages in the background on a schedule or on demand. It gives you static-file speed and low hosting cost while still letting content update without a full redeploy.
Where to start
If you have a content or marketing site running full server-side rendering, audit which pages actually need per-request data. Move everything else to ISR with a sensible revalidate window and watch your function invocations drop. That one change usually pays for itself in the first billing cycle.
Tired of re-keying the same data between tools? Pylonworks builds custom automation and internal tools for businesses without a developer, on a fixed quote you approve up front. Tell us what's eating your time