Article

Lessons from building and deploying a Next.js application

12 October 2026 · Francisco Gaspar

Next.js has been the interface, not the place the data lives.

On a client marketplace there are two Next.js apps, the marketplace and the admin, in front of one NestJS API. Negotiation chat is Socket.IO. The apps subscribe. They do not pretend a server component is the chat. Search results come from the API, which reads Meilisearch. Those apps and the API deploy to Azure with Terraform. The durable writes, including the outbox in PostgreSQL, stay in NestJS.

On a client audit product the Next.js app is the dashboard: creating a workspace and inviting people into it. The audits run in FastAPI workers. The dashboard starts a job and shows what came back. The browser agents, the queue and the retries are not in the Next.js process. The deploy is the same shape, Azure and Terraform, for the dashboard and for the workers.

Soon and LongTable go the other way. The website is Next.js, the data is Supabase, and the phone apps are Expo. LongTable’s restaurants are one catalogue shared by the site and the apps. Soon reads bill emails and will not put an amount on the calendar unless it has been checked. An uncertain value stays blank.

The boundary is the lesson. Next.js is a good place for the screens and the session. It is a bad place for work that has to be retried, reported to a regulator, or shared with a mobile app. That work stays in the API, and the deploy follows the API.

This CV is the exception on purpose. It has no API, so it is Astro on Cloudflare Workers.

Experience and projects