Tablas que necesita todo SaaS:el plano de base de datos

Las 10 tablas que necesita todo SaaS sostienen el 90% de las aplicaciones de negocio: organizaciones, usuarios, miembros de la organización, tu entidad principal, categorías, relaciones, registro de actividad, archivos, notificaciones y ajustes. No reinventas la base de datos: clonas esta estructura, cambias un par de nombres y lanzas. Aquí tienes el plano completo, cómo se conectan las tablas y el prompt para copiar y pegar que hace que la IA construya todas bien.

Una tabla no es más que una hoja de cálculo estructurada: cada fila es una cosa (una tarea, un contacto, una factura) y cada columna es información sobre esa cosa. Si esto te suena nuevo, empieza por las bases de datos explicadas para fundadores no técnicos y vuelve. La idea de este artículo es más sencilla: no necesitas entender de bases de datos para diseñar una. Necesitas saber qué tablas crear, y son casi las mismas en todos los SaaS.

Las 10 tablas que necesita todo SaaS

Un mal diseño de base de datos rompe tu app cuando escalas. Un buen diseño hace que simplemente funcione. Esta es la base:

Fíjate en lo poco que es específico de tu idea. El 90% de tu base de datos es igual que la de cualquier otra app de negocio; el 10% es tu lógica de negocio única. Empieza por el 90%, construye el 10% y lanza tu producto.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Cómo se conectan las tablas

Piensa en un edificio de apartamentos. Las organizaciones son el registro del edificio: la lista de inquilinos. Los usuarios son los residentes. Los miembros de la organización son el directorio de apartamentos que dice que Juan vive en el 5 y Sara en el 12. A partir de ahí, la cadena es lógica: una organización tiene muchas de tu entidad principal (tareas, contactos, facturas), cada una puede tener archivos adjuntos, cada acción genera una entrada en el registro de actividad y los eventos importantes crean notificaciones.

Un ejemplo concreto: un CRM sencillo necesita organizaciones (tus clientes), usuarios (quienes inician sesión), miembros de la organización (Juan trabaja en una empresa, Sara en otra), contactos (los registros del CRM), etiquetas de contacto (lead caliente, lead frío, cliente), un registro de actividad (cada interacción), archivos (documentos adjuntos a los contactos), notificaciones (alertas cuando un contacto actúa) y ajustes (preferencias por organización). Eso es todo. Nueve tablas. Un CRM completo.

Por eso también funciona tan bien diseñar las tablas antes de construir las pantallas, que es todo el argumento del desarrollo con la base de datos primero. Las pantallas cambian cada semana. Esta estructura casi no cambia.

Las tablas que no necesitas al lanzar

Tan importante como las diez que construyes son las que te saltas. Añádelas más adelante, cuando realmente las necesites:

• Facturación y suscripciones: añádela cuando estés listo para cobrar
• Equipos: añádelos cuando las organizaciones crezcan
• Integraciones: añádelas cuando te conectes con otras herramientas
• Informes: añádelos cuando los usuarios necesiten analítica
• Webhooks: añádelos cuando construyas una API
• Registros de auditoría: añádelos para requisitos de cumplimiento y seguridad

La regla: empieza pequeño y añade tablas según las necesites. La base de datos es una capa de un cuadro más grande (los 18 sistemas que necesita todo SaaS traza el resto), pero las tablas son por donde se empieza, porque todo lo demás se apoya en ellas.

El prompt para copiar y pegar que construye las 10

No escribes este SQL tú. Le das a la IA el plano y los requisitos de calidad en un solo prompt:

Create these database tables for a multi-tenant [your app type]:

FOUNDATION: 1. organizations (id, name, slug, settings, tier, is_active, created_at, updated_at) · 2. users (handled by Supabase Auth) · 3. organization_members (organization_id, user_id, role)

CORE FEATURE: 4. [your main entity] with organization_id, your specific fields, audit columns

SUPPORTING: 5. categories (for organising [your main entity]) · 6. files (attachments) · 7. activity_log (tracking all actions) · 8. notifications (user alerts) · 9. settings (preferences)

Requirements: every table needs organization_id (except users) · add indexes on all foreign keys · enable Row-Level Security · use soft deletes (deleted_at column) · add audit columns (created_at, created_by, updated_at, updated_by)

Show me the complete SQL migration.

La IA generará las tablas, bien conectadas, multi-tenant y listas para producción. El bloque de requisitos no es decoración opcional: el organization_id en cada tabla y la Row-Level Security son lo que impide que el Cliente A vea alguna vez los datos del Cliente B.

El mínimo para lanzar

Antes de empezar a construir funcionalidades, comprueba que tienes: una tabla de organizaciones, usuarios (Supabase la proporciona), miembros de la organización, tu entidad principal, al menos una forma de organizar elementos, un registro de actividad y notificaciones. Con estas 7 tablas mínimas puedes construir y lanzar. Añade el resto a medida que crezcas.

La mayoría de los fundadores pasan semanas angustiados con el diseño de la base de datos como si su app fuera un copo de nieve único. No lo es, y eso es una buena noticia. La base es un problema resuelto. Clónala, personaliza el 10% y dedica tu energía a la parte que solo tú puedes construir.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Necesito de verdad las 10 tablas antes de lanzar?

No: 7 son el mínimo: organizaciones, usuarios, miembros de la organización, tu entidad principal, una forma de organizar elementos (categorías o etiquetas), un registro de actividad y notificaciones. Archivos, relaciones y ajustes pueden llegar con las funcionalidades que los necesiten. Facturación, equipos, integraciones, informes y webhooks vienen todavía después.

¿Qué significa "multi-tenant" y por qué importa?

Multi-tenant significa que muchos clientes comparten una misma app y cada uno ve solo sus propios datos. Por eso la tabla de organizaciones va primero y por eso cada tabla lleva un organization_id. Combinado con la Row-Level Security, garantiza que los registros de cada cliente se queden dentro de sus propias paredes, como los apartamentos de un mismo edificio.

¿Puede la IA diseñar de verdad mi base de datos?

Sí, si le das el plano. Pega el prompt de arriba con tu entidad principal rellenada y la IA produce la migración SQL completa: tablas, claves foráneas, índices y Row-Level Security. Lo que la IA no puede hacer es decidir cuál es tu entidad principal. Esa es una decisión de producto, no técnica.

¿Cuál es la "entidad principal" de mi app?

Lo único que gestiona tu app. Gestor de tareas → tareas. CRM → contactos. Facturación → facturas. Reservas → citas. E-commerce → productos. Si no puedes nombrarla en una palabra, aún no has definido tu producto con suficiente precisión: resuélvelo antes de tocar la base de datos.