Pour un SaaS Next.js qui démarre, Vercel supprime quasiment toute l'infra : tu pushes, c'est en ligne, en global. Voici ce que ça te fait gagner concrètement — et le moment précis où il faut envisager d'en partir.
Vercel est l'éditeur de Next.js : le framework et la plateforme sont pensés ensemble. Pour un SaaS qui démarre, ça veut dire zéro serveur à gérer, et tout le temps qui va au produit plutôt qu'à l'infra.
git push et c'est déployé. Pas de serveur, pas d'OS, pas de reverse proxy à configurer.
Chaque pull request a son URL de preview isolée. La revue devient concrète, testable, partageable.
Ton app est servie près de l'utilisateur, partout, sans que tu gères le moindre CDN.
Un pic de trafic est absorbé sans rien faire : les fonctions serverless montent seules.
La contrepartie de cette simplicité : tu paies la commodité, et tu vis dans un modèle serverless. Deux choses à garder en tête avant de bâtir dessus.
Le modèle serverless a des limites de durée d'exécution : un traitement long (export massif, batch) doit partir ailleurs — une queue, un worker, une Lambda dédiée.
Rester sur Vercel tant que ça sert le produit, migrer quand ça devient un frein — pas avant. Les signaux : une facture qui dépasse ce que coûterait ton propre EC2, un besoin de workloads que le serverless ne gère pas, ou des contraintes de conformité qui imposent ton infra.
Le jour venu, les chemins de migration sont dans héberger son SaaS sur AWS — souvent, on garde le front sur Vercel et on déporte juste le lourd.
Vercel est le meilleur point de départ pour un SaaS Next.js : tu échanges du contrôle contre de la vitesse, et au début la vitesse gagne toujours. Construis dessus sans culpabiliser, surveille la facture, et garde une porte de sortie ouverte pour le jour où l'échelle change la donne.
Vercel — Pricing ↗