Tu primera elección de backend es una apuesta de producto. Decide qué tan rápido publicás el próximo feature y qué tan cara se vuelve la primera conversación seria de escala.
Empezá por la siguiente etapa, no por el logo
Preguntá:
- ¿Qué modelo de auth y tenancy necesitamos en 12 meses?
- ¿El reporting se queda simple o se vuelve relacional y analítico?
- ¿Quién en el equipo domina las restricciones de la plataforma?
- ¿Qué pasa cuando un buyer enterprise pide audit logs y residencia de datos?
Comparación rápida
| Opción | Fortaleza | Riesgos |
|---|---|---|
| Firebase | Arranques mobile/realtime rápidos | La complejidad relacional y los patrones de query pueden doler |
| Supabase | Familiaridad SQL + Postgres | Todavía hace falta disciplina en RLS, migraciones y límites de servicio |
| Custom (Node/Nest, etc.) | Control total para dominios complejos | Costo inicial más alto. Necesita liderazgo senior |
Para el mano a mano: Firebase vs Supabase para startups.
Cuando lanzar en baas deja de ser barato
- Los permisos multi-tenant se vuelven un laberinto de reglas
- Finance/ops necesita reportes que la plataforma pelea
- La superficie de integración supera el glue code
- Las curvas de costo sorprenden después de picos de uso
Ahí desarrollo backend para startups suele ser el camino más barato que otro año de arquitectura accidental.
Una regla de founder
Optimizá por velocidad reversible. Preferí plataformas que permitan extraer una capa de servicios después sin reescribir el negocio.
Relacionado: arquitectura MVP escalable y decisiones de infraestructura al escalar.
