Construire vite sans fabriquer une dette technique impossible à rembourser

Le piège du « on refactorera plus tard »

Quand un produit doit sortir vite, la tentation est forte d'empiler des raccourcis : logique métier dans les composants, endpoints sans contrat clair, données dupliquées entre le front et le back. Au début, tout fonctionne. Puis chaque nouvelle feature coûte deux fois plus cher.

Un MVP sain n'est pas un prototype jetable. C'est un premier incrément maintenable : assez léger pour shipper, assez structuré pour grandir.

Trois décisions qui paient tôt

1. Séparer ce qui change de ce qui ne change pas

Identifiez les règles métier stables (facturation, permissions, parcours critiques) et isolez-les du rendu UI. Même sans microservices, un module services/ ou lib/domain/ évite que React devienne votre base de données applicative.

2. Typage et contrats dès le jour 1

TypeScript strict, schémas de validation (Zod ou équivalent) aux frontières API, et messages d'erreur explicites. Ce n'est pas de la sur-ingénierie : c'est de la documentation exécutable qui accélère l'onboarding et réduit les régressions.

3. Mesurer avant d'optimiser, mais ne pas ignorer la perf

Un portfolio ou un SaaS B2B doit rester rapide sur mobile 4G. Images optimisées, bundles raisonnables, Server Components quand l'interactivité n'est pas requise. La perf est une feature produit, surtout quand vous vendez de la fiabilité.

Ce que j'évite volontairement

• Multi-tenant, event sourcing ou CQRS avant d'avoir des utilisateurs payants
• Abstractions « pour un jour » sans cas d'usage concret
• Dépendances lourdes pour résoudre un problème qu'une dizaine de lignes résout

En résumé

Construire vite, ce n'est pas construire sale. C'est choisir les compromis visibles : reporter le nice-to-have, garder les fondations propres, documenter les dettes assumées. Votre futur vous — et vos premiers clients — vous remercieront.