Next.js · Switzerland

Next.js developer in Switzerland.

I build production Next.js applications: App Router, Server Components by default, server actions for forms, Postgres or Supabase for data, Stripe for payments, Resend for email, caching and rendering chosen per page, SEO and structured data built in, monitoring and deployment on Vercel. Seven of my own products run on this stack; so does this site.

Updated

In brief

Where
Zürich, Switzerland — remote across Switzerland and Europe
Version
Next.js 16, App Router, React 19, React Compiler, strict TypeScript
Data
Postgres (Supabase or Neon), versioned migrations, typed access
Payments · Email
Stripe with signed webhooks · Resend + React Email
Deployment
Vercel — preview per branch, Fluid Compute, analytics
Built and run
Atamatax · Horvera · Wabiro (in production) · SponsorsMetrics (private beta) · bynilson.ch

Next.js is the most productive framework I know for shipping a complete web product with one person — provided it is used as a production framework, not a demo generator. The difference comes down to a few decisions: what renders on the server, where business logic lives, how data is validated, what is cached, and how you know it works.

This page answers a commercial question: why hand a Next.js application to me rather than an agency or a generalist. The answer is in the products at the bottom of the page — and in how they are built.

01 — Production

What a production Next.js application requires

The decisions that separate a Next.js project that holds from one that gets rewritten after a year.

App Router and Server Components
Rendering happens on the server by default: less JavaScript shipped, pages readable by search engines without execution, data read right where it is displayed. Client components are the exception, reserved for real interactivity.
Server actions for forms
A form is a `<form>` bound to a server action: it works without JavaScript, validates on the server with Zod, redirects to its result state. No API layer to maintain for every screen.
API routes where they belong
Stripe webhooks, third-party integrations and public endpoints stay route handlers — signed, idempotent, logged. Everything else goes through actions.
Authentication and authorisation
Server-side sessions (Supabase Auth or a direct implementation), a check on every data read, permissions modelled in the database. Route protection lives in the proxy and in the queries, not only in the UI.
Postgres and typed access
A versioned Postgres schema, typed queries, transactions where several writes must succeed together. Supabase when its managed parts (auth, storage, RLS) save weeks; bare Postgres when they would get in the way.
Caching and rendering
Static when the content allows it, dynamic when it depends on the user, revalidated when data changes. Every page has a rendering strategy that was chosen, not inherited.
SEO and structured data
Per-page metadata, canonical and hreflang, sitemap and robots generated from data, JSON-LD consistent with the visible content, generated Open Graph images. This site is the example.
Performance
Self-hosted fonts, inlined CSS, optimised images, no unnecessary third-party script, CSS animations. Core Web Vitals are a result of the architecture, not an end-of-project optimisation.
Observability and deployment
Vercel with a preview per branch, documented environment variables, analytics and error logs wired from the first deployment, migrations in the pipeline.

02 — Why

Why hand a Next.js product to me

Because I operate several. Atamatax, Horvera, Wabiro and SponsorsMetrics are Next.js applications in production, with real payments, real users and the real problems that come with them — migrations, missed webhooks, programmatic pages to index, costs to watch. What I offer is not an opinion on Next.js; it is a practice.

Because this site is built the same way: Server Components everywhere, a deferred vanilla-JavaScript interactive layer, forms as server actions that work without JavaScript, Stripe and Supabase called over REST without SDKs, locale routing in the proxy, sitemap and JSON-LD derived from data. You can inspect it.

Because one person carries the architecture, the data model, the interface and the deployment: nothing is lost between a designer, a front-end developer and a back-end developer. The repo is yours, documented, with no dependency on me.

03 — Choice

When Next.js is the right choice — and when not

The right choice
A SaaS product, a client portal, a site where search matters, an application with forms, dashboards and payments. Anything that benefits from server rendering, simple deployment and one language end to end.
Worth discussing
A very rich client-side application (editor, canvas, heavy real-time) — Next.js works, but the value of server rendering is smaller and the architecture must isolate the client part.
Not the right choice
A heavy data-processing or long-computation backend — Next.js stays the front, and the processing lives in a dedicated service (Python, job queues). A native mobile app. A five-page brochure site with no planned evolution, where a static generator will do.

04 — Cost

What a Next.js application costs

The framework does not set the price; the scope does. A Next.js application with authentication, one core flow, payments and deployment sits at the low end of a SaaS v1 — around CHF 20’000; with multiple roles, a data dashboard and integrations, up to CHF 45’000. Below CHF 20’000 — a brochure site, a theme — I do not take the project; rebuilding an existing Next.js application is priced separately. The SaaS cost calculator places your project in five minutes; the details are in How much does a SaaS v1 cost in Switzerland.

Scope it with the calculator

Five minutes. A complexity band, not a quote.

Is this the right service?

This makes sense if

  • You are launching a web product — SaaS, portal, tool — and want it fast, indexable and maintainable from day one.
  • You have an existing Next.js application that needs a production architecture: auth, data, payments, caching, SEO, monitoring.
  • You want one person from the Postgres schema to the deployment, with a price known upfront.

It is not the right service if

  • You are looking for a front-end developer to slot into an existing team by the hour.
  • The core of the project is heavy data processing or a native mobile app.
  • You want to learn Next.js yourself — the Build School is made for that.
  • You are looking to employ a Next.js developer — the hire-or-outsource guide helps you decide, with nothing to sell.

How it works

Four steps, fixed scope, price agreed upfront.

  1. 01

    Diagnose

    20 minutes, free. Business model, workflows, risks and product scope. If I’m the wrong person, I say so.

  2. 02

    Architect and propose

    Within 48h: data model, system boundaries, integrations, UX — and one fixed fee with dated milestones. No “starting at”.

  3. 03

    Build

    4 to 6 weeks of controlled iterations. A demo every Friday on a Vercel preview. You watch the system grow live — no black box.

  4. 04

    Launch

    Payments, analytics, deployment, operational workflows. You leave with the repo, the accounts, the pipeline — and 30 days of 24h replies.

  5. 05

    Improve

    Measured iteration on real usage: a fresh fixed-fee scope per increment, or nothing if your team takes over. No hidden dependency.

The full process, guarantees and prices →

Frequently asked questions

  • How much does a Next.js application cost?

    The framework does not set the price; the scope does. Expect around CHF 20’000 for an application with authentication, one core flow, payments and deployment, up to CHF 45’000 with multiple roles, a dashboard and integrations. Fixed fee, price agreed before work starts.

  • Do you need Supabase with Next.js?

    Not necessarily. Supabase saves weeks when managed authentication, file storage and access policies are needed. Bare Postgres (Neon, or Supabase’s Postgres without its services) fits better when access logic lives entirely on the server. The choice is made during scoping.

  • Server actions or API routes?

    Both, in their place. User-triggered forms and mutations go through server actions — simpler, working without JavaScript. Webhooks, integrations and anything a third party calls stay route handlers.

  • Is Next.js good for SEO?

    Yes, when pages are server-rendered and metadata, sitemap, canonicals and structured data are generated from data. This site and Horvera — with its programmatic pages — are examples. A Next.js application rendered only on the client loses that advantage.

  • Can I take over the code after delivery?

    It is built for that. Strict TypeScript, standard App Router structure, no unnecessary home-made abstraction, documented environment variables and pipeline. A Next.js developer finds their way around in a day.

  • Hire a Next.js developer or outsource?

    Hire if your Next.js product has a continuous roadmap and someone in-house can direct the work. Outsource a defined scope — a v1, a rebuild, a production hardening — when it can be written as acceptance criteria and a team will take it over. The hire-or-outsource guide prices both.

A Next.js application to build or put right?

Describe the product, its current state if it exists, and the date that matters. A 20-minute scope call, free.

danilson.daveigaramos.pro@gmail.com · Reply within 24h, Mon–Fri.