Con tus respuestas cerradas: sin pagos en la app, restaurantes de alta manual, comensal solo consulta, vídeos 100% tuyos (fotógrafo profesional), ES+EN, datos en la UE, presupuesto 20–30 €/mes, plazo total 4–6 semanas. Este dossier fija las decisiones, lista los requisitos rankeados (los puedes reordenar y excluir en la pestaña "Requisitos") y los convierte en un plan de tareas por semanas con seguimiento.
Preguntaste si V2 se construye "a partir de aquí" o de cero. Respuesta: V1 es el embrión de V2, no un desvío. Todo lo que se hace en las semanas 1–2 se reaprovecha:
En V1 la carta vive en ficheros de contenido (un directorio por restaurante). En V2 pasa a Supabase. El frontend es el mismo; solo cambia de dónde leen los datos. Por eso V1 no es trabajo tirado: es la mitad del frontend de V2 ya validada con restaurantes reales de Badajoz.
git push.qr-code-styling (gratis). Imprimes y listo./es y /en con el mismo contenido traducido.Todo el presupuesto queda libre para V2. Y si un restaurante de Badajoz te dice que sí mañana, V1 se le entrega en días.
// Ejemplo real del árbol del camarero guiado (V1 y tier base de V2)
{ "id": "inicio",
"camarero": "¡Hola! Soy tu camarero. ¿Qué te apetece hoy?",
"botones": [
{ "texto": "🌱 Opciones sin gluten", "accion": "filtrar:sin_gluten" },
{ "texto": "🍷 Recomiéndame un vino", "ir_a": "maridaje" },
{ "texto": "⭐ Lo más pedido", "ir_a": "populares" },
{ "texto": "🥗 Algo ligero", "accion": "filtrar:ligero" } ] }
Me pediste investigar si Supabase "es lo más adecuado" o hay algo mejor para apoyarte en cosas hechas. Comparé las cuatro opciones serias:
| Plataforma | Multi-tenant sin datos cruzados | Coste | UE | Veredicto |
|---|---|---|---|---|
| Supabase (Postgres gestionado + Auth + Storage) | ✓✓ Row-Level Security nativo: la propia BD rechaza cualquier consulta fuera del tenant, aunque el código tenga un bug | Free (desarrollo) → Pro 25 $/mes | ✓ regiones AWS UE (Frankfurt, Irlanda, París…) | Elegida |
| Firebase (Google) | ◑ reglas NoSQL, más fáciles de romper; sin SQL | variable, difícil de predecir | ◑ parcial | No — lock-in y modelo de datos peor para cartas |
| PocketBase (self-host) | ◑ reglas propias sobre SQLite | gratis + tu VPS | ✓ | No — vuelves a mantener servidor tú, justo lo que quieres evitar |
| Appwrite Cloud | ◑ permisos por documento, menos maduro que RLS | Free → 15 $/mes | ✓ | Alternativa B — válida pero con menos ecosistema |
tenant_id + tests de fuga automatizados.waiter_engine.tenants con tema (colores/logo/tipografía) y dominio propio opcional. Meterlo después es carísimo; ahora es una columna más.Supabase Free + hosting gratis + Bunny céntimos. Semanas 3–6.
Supabase Pro 25 $ + Bunny + IA (~1-3 € con decenas de conversaciones/día). En presupuesto.
5×29 € a 5×89 € por transferencia. El coste técnico es ruido desde el primer cliente.
Lo marcaste como fundamental, así que lo dejo definido a nivel de implementación, no de intención:
tenant_id NOT NULL con clave foránea a tenants.tenant_id coincide con el del usuario autenticado (JWT de Supabase Auth). La BD lo impone aunque el código falle.publicado = true del slug pedido. El anónimo no puede listar tenants.-- cada tabla del sistema: ALTER TABLE platos ENABLE ROW LEVEL SECURITY; CREATE POLICY aislamiento_tenant ON platos USING ( tenant_id = ( SELECT tenant_id FROM perfiles WHERE user_id = auth.uid() ) ); -- lectura pública SOLO de lo publicado: CREATE POLICY carta_publica ON platos FOR SELECT TO anon USING ( publicado = true );
En la pestaña Requisitos tienes los 36 requisitos rankeados por prioridad. Reordénalos con ▲▼, excluye los que no quieras y filtra por versión, prioridad o categoría.
En Plan semanal, cada requisito ya está convertido en tareas ancladas a las semanas 1–6. Marca casillas según avances; la barra de progreso se actualiza. Si excluyes un requisito, sus tareas se atenúan.
El orden, exclusiones y tareas hechas se guardan con Exportar JSON (descarga un fichero) y se recuperan con Importar. Así tu progreso vive contigo, no en el navegador.
Prioridad tipo MoSCoW: MUST sin esto no hay producto · SHOULD importante, no bloquea · COULD deseable · LATER aparcado a V2+. Usa ▲▼ para re-rankear y ✕ para excluir (sus tareas se atenuarán en el plan).
Semanas 1–2 = V1 publicada y vendible en Badajoz. Semanas 3–6 = V2 con Supabase, panel y camarero IA. Las tareas de requisitos excluidos aparecen atenuadas y no cuentan para el progreso. Exporta tu JSON al terminar cada sesión.
S1: web V1 desplegada con 1 restaurante demo y vídeo real tuyo · S2: V1 completa (chat guiado + QR + ES/EN) publicada y enseñable a restaurantes de Badajoz · S3: Supabase con RLS probado con tests de fuga en verde · S4: panel admin operativo, tú das de alta un restaurante en <10 min · S5: camarero IA respondiendo solo con datos de la carta · S6: 2–3 restaurantes piloto migrados a V2 y checklist de seguridad pasada.