PDR-STACK-001 — Stack Tecnológico del SaaS Contable

Propósito: Documentar y justificar el stack tecnológico de Átomo. Es la decisión que determina el costo de desarrollo, el costo de operación por tenant, la velocidad de entrega y la capacidad de implementar la reexpresión por inflación en el futuro.

1. Metadatos

PDR-ID: PDR-STACK-001
Título: Stack tecnológico — Frontend React + Backend Supabase/PostgreSQL + Monorepo
Estado: BORRADOR
Dominio: priorizacion
Fecha: 2026-08-07
Autor: LEDGER-ARCHITECT (Protonion)

2. Hipótesis de Negocio

Creemos que el stack React + Supabase (PostgreSQL con RLS) es el punto óptimo entre velocidad de entrega, costo de operación por tenant y capacidad de cumplir la partida doble con integridad garantizada a nivel de base de datos, porque permite imponer las invariantes contables (Debe=Haber, inmutabilidad, tenant_id) con CONSTRAINTS y RLS nativos.

Problema: Un sistema contable no puede darse el lujo de errores: la integridad debe estar garantizada en la base de datos, no solo en la lógica de la aplicación. Y el presupuesto del MVP es ajustado.

Solución propuesta:
- Frontend: React 18 + TypeScript + Vite + TailwindCSS (patrón ProyectoNaif, probado por el equipo).
- Backend: Supabase (PostgreSQL 16 + Auth + RLS + Edge Functions en TypeScript).
- Base de datos: PostgreSQL — CONSTRAINTS de partida doble, RLS multi-tenant, numeric exacto para montos.

Mecanismo causal: PostgreSQL permite CHECK (monto >= 0), triggers de inmutabilidad y RLS por tenant como capa de seguridad independiente de la aplicación → la integridad contable sobrevive incluso a un bug de la app.

3. Decisión

Adoptamos monorepo con frontend React (Vite/TypeScript/Tailwind) + backend Supabase (PostgreSQL 16 + RLS + Edge Functions) como stack de Átomo.

• QUÉ se decide: PostgreSQL como único motor de datos (con numeric(18,2) para montos, CONSTRAINTS de partida doble, RLS por tenant). Frontend en React con Astronaut Protocol. Auth vía Supabase Auth (email/password + magic link).
• QUÉ NO se decide: No usamos microservicios en Fase 1 (monolito modular + Edge Functions para tareas específicas como cálculo de IVA por lote). No usamos NoSQL. No usamos serverless de terceros para el core contable.
• POR QUÉ: El stack es el mismo probado en ProyectoNaif (el equipo lo domina), PostgreSQL es el estándar de oro para integridad transaccional, y el costo de operación es predecible ($0-25/mes de infraestructura).
• CUÁNDO: Fase 1.

4. Contexto y Alternativas Consideradas

4.1 Alternativa A — React + Supabase/PostgreSQL (ADOPTADA)

4.2 Alternativa B — Python/FastAPI + PostgreSQL (estilo ZF)

4.3 Alternativa C — Next.js full-stack (API Routes + Prisma + PostgreSQL)

5. Premisas de Negocio Vinculadas

6. Supuestos No Validados (Riesgos)

7. Métricas de Validación

7.1 Señal Verde (Decisión Validada)

• Operación ≤ $25/mes con 50 tenants.
• Los CONSTRAINTS de partida doble se cumplen en producción.

7.2 Señal Roja (Pivot Trigger)

• El costo de operación escala por encima de $100/mes con pocos tenants.
• Limitaciones de Edge Functions bloquean una funcionalidad P0.

8. Análisis de Riesgos (360°)

9. Puerta de Retroceso (Pivot/Escape Hatch)

Condición de pivot: El costo de operación supera $100/mes con menos de 100 tenants activos, o una funcionalidad P0 queda bloqueada por límites del proveedor.

Nuevo rumbo: Migrar el backend a FastAPI/Python + PostgreSQL (el equipo ya lo hizo en ZF), manteniendo el frontend React. El schema SQL es portable.

Costo de pivot: 200-300h. Alto pero acotado gracias al SQL portable.

Ventana de decisión: 12 meses post-lanzamiento.

10. Referencias

11. Firmas

12. Historial de Cambios

Fin del PDR — Stack Tecnológico