Cada studio tiene un stack "de la casa". El riesgo es que se vuelva dogma: lo usas porque siempre lo usaste, no porque sea lo correcto para este proyecto. Nosotros construimos sobre Supabase + Netlify, y este artículo es la versión honesta de por qué — incluyendo los casos en los que te diríamos que no es la herramienta.
No es magia. Es una serie de decisiones de ingeniería con ventajas reales y límites reales.
Qué resuelve cada pieza
Supabase es el backend: una base de datos PostgreSQL de verdad con autenticación, almacenamiento de archivos, tiempo real y funciones serverless (edge functions) encima. No es una base "tipo nube" propietaria — es Postgres estándar, el mismo motor que corre en bancos y aerolíneas.
Netlify es el frente: hospeda el sitio o la app web, hace el deploy automático con cada cambio y lo sirve desde una red global. Subes código, en segundos está en producción.
Juntos cubren el 90% de lo que una plataforma de negocio necesita el día uno, sin que tengas que ensamblar diez servicios distintos a mano.
Por qué este stack, en concreto
1. Velocidad de entrega sin atajos baratos
La autenticación, el almacenamiento de archivos, el chat en tiempo real — son problemas resueltos. Reescribirlos desde cero es tiempo que le quitas a lo que de verdad diferencia tu producto. Supabase nos los da listos y endurecidos, así que el equipo gasta sus horas en la lógica de tu negocio, no en reinventar un login seguro.
Así entregamos Hypothek en 12 días: un portal multi-rol de 8 etapas operativas, con documentos, chat y notificaciones — funcionando en producción. Ábrelo y compruébalo.
2. Postgres real + seguridad por filas (RLS)
Esta es la pieza que más importa y la que menos se nota desde afuera. Postgres trae Row Level Security: reglas, escritas dentro de la base de datos, que deciden qué fila puede ver o tocar cada usuario. Un cliente solo ve su expediente. Un asesor solo ve los suyos. Un administrador ve todo.
La diferencia clave: esas reglas viven en la base, no en el código de la pantalla. Aunque alguien manipule la app desde el navegador, la base de datos sigue diciendo que no. La seguridad no depende de que el frontend "se porte bien".
En una plataforma con datos sensibles —financieros, médicos, personales— la pregunta no es "¿se ve bien?" sino "¿quién puede leer esa fila aunque rompa la interfaz?". RLS responde eso en la capa correcta.
3. Deploy atómico y reversible
Cada cambio que sube a Netlify es una versión completa e independiente. Si algo sale mal, vuelves a la versión anterior en un clic — no hay un estado "a medias" donde la mitad del sitio es vieja y la otra nueva. Para un equipo pequeño que itera seguido, esto elimina toda una categoría de incidentes de madrugada.
4. Costo bajo al inicio, predecible al crecer
Ambos tienen planes gratuitos que aguantan un producto en validación, y suben de precio de forma escalonada conforme creces. No pagas infraestructura de empresa grande para validar una idea. Eso es parte de cómo Hypothek costó ~$90K en vez de ~$600K frente a una agencia tradicional.
5. Sin lock-in propietario
Este es el punto que casi nadie revisa hasta que es tarde. Como Supabase es Postgres estándar, tu base de datos es portátil. Si algún día quieres mudarte a tu propio servidor o a otra nube, te llevas el Postgres completo — el esquema, los datos, las reglas. No estás casado con un formato propietario que solo ese proveedor entiende.
pg_dump. Con bases propietarias, la respuesta a veces es "no puedes". Esa diferencia es tu palanca de negociación de por vida. Y como el código es tuyo —ese es nuestro modelo—, no dependes de nosotros para mudarte.Cuándo NO conviene
Si el stack solo tuviera ventajas, este sería un folleto, no un artículo técnico. Hay casos en los que te diríamos que busques otra cosa:
- Cómputo pesado y sostenido. Procesamiento de video, entrenamiento de modelos, simulaciones numéricas, trabajos que corren minutos u horas. Las edge functions son para tareas cortas; para esto necesitas servidores dedicados o infraestructura de cómputo especializada. Forzarlo aquí es pelear contra la herramienta.
- Tu equipo ya está casado con otro stack. Si tu gente vive en .NET, Java o Django y los mantiene bien, migrar por moda es tirar conocimiento a la basura. El mejor stack también es el que tu equipo sabe operar a las 3 a.m.
- Requisitos on-premise o regulatorios estrictos. Algunos sectores exigen que los datos vivan en un servidor propio, en un país específico, bajo certificaciones puntuales. Supabase se puede auto-hospedar (otra vez: es Postgres), pero entonces cargas tú con la operación — y a veces conviene una solución pensada para ese marco desde el inicio.
- Escalas extremas muy particulares. Cargas globales de altísimo tráfico con patrones raros pueden pedir arquitecturas a la medida. No es el caso del 95% de las PyMEs, pero si es el tuyo, hay que diseñarlo aparte.
La regla honesta: este stack es excelente para plataformas de negocio —portales, paneles, CRMs, marketplaces, productos con usuarios, roles y datos—. No es la herramienta para todo, y quien te diga que su stack sirve para todo te está vendiendo, no aconsejando.
En resumen
Elegimos Supabase + Netlify porque nos deja entregar rápido, con seguridad en la capa correcta, a costo bajo y sin amarrarte a un proveedor. Y te decimos sus límites porque la decisión correcta sale de conocer ambos lados.
¿Tienes un producto en mente y quieres saber si este stack —u otro— es el adecuado? En XX Disruptive Minds te damos la recomendación técnica honesta, con casos en producción que puedes abrir. Agenda un diagnóstico.