La pregunta más honesta que me hizo un founder esta semana

Una auditoría técnica de SaaS es un diagnóstico estructurado de seis o siete áreas críticas (seguridad, datos, pagos, observabilidad) que revela qué puede romperse en producción y en qué orden hay que arreglarlo. La buena noticia: el 80% del valor de un audit lo conseguís vos solo, respondiendo cinco preguntas concretas en una tarde.

Un founder me escribió ayer:

"Armé mi MVP con Lovable + Supabase. Tengo 3 clientes piloto. Estoy seguro que algo está mal pero no sé qué. ¿Cómo lo audito sin que me cobren USD 5.000?"

Le respondí lo mismo que respondo siempre: el primer audit no es sobre tu código. Es sobre 5 preguntas que vos mismo podés responder.

¿Qué es una auditoría técnica de SaaS y cuándo conviene?

Una auditoría técnica revisa cómo se comporta tu sistema ante los escenarios que no aparecen en el demo: un usuario malicioso, un pago duplicado, una base llena, una integración caída. Para SaaS construidos con vibe coding (Cursor, Lovable, Bolt, v0) el audit cubre puntos predecibles: autenticación bypaseable, RLS desactivada, webhooks sin firma, backups no testeados, observabilidad cero.

Cuándo conviene auditarlo:

• Antes del lanzamiento público (de "amigos que prueban" a "cliente que paga").
• Después de los primeros 5-10 clientes reales, cuando empezás a ver patrones de uso que no anticipaste.
• Cuando estás por levantar capital y debido diligence técnica es parte del proceso.
• Después de cualquier incidente que te haya asustado (un cliente vio datos de otro, un pago raro, un downtime largo).

Lo que no es un audit: una reescritura, un refactor, una segunda opinión sobre el stack. Es un diagnóstico que termina en un roadmap priorizado, no en código nuevo.

¿Cuáles son las 5 preguntas críticas?

Estas cinco son las que filtran el 80% de problemas serios en SaaS vibe-coded. Si respondés con honestidad, sale el roadmap solo.

1. ¿Las API keys están en el frontend?

Abrí el browser, F12, Network tab, recargá la app. Buscá strings que arrancan con sk_, pk_, eyJhbG..., Bearer, Authorization. Si encontrás cualquier secret que no sea una public key explícita (anon de Supabase, publishable de Stripe), está expuesto al mundo. Cualquier visitante puede leerlos.

Por qué pasa con vibe coding: los modelos generan código rápido y a veces dejan el secret hardcoded en un componente cliente porque "así funcionaba". El fix es mover la llamada al backend y usar env vars server-side.

2. ¿Tenés Row-Level Security activada en Supabase?

Entrá al dashboard de Supabase → Database → Tables → cada tabla. Mirá el toggle "RLS enabled". Si está apagado en alguna tabla con datos de usuarios, cualquier persona con el anon key (que está en tu frontend) puede leer todo. Sin RLS, tu autenticación es decorativa.

Por qué pasa con vibe coding: Supabase trae RLS apagado por default. El modelo arma el schema, vos hacés un INSERT desde la app, "anda perfecto" — pero estás bypaseando la verificación a nivel base. Activar RLS y escribir policies por tabla es la única forma de que la base imponga seguridad, no la app.

3. ¿Tus webhooks de Stripe validan firma?

Buscá en tu código del endpoint de webhook (/api/webhook, /api/stripe, similar). ¿Llamás a stripe.webhooks.constructEvent(body, signature, secret) o estás aceptando cualquier POST que matchee el schema?

Si no validás firma, cualquier persona puede mandarte un POST falsificando un evento checkout.session.completed y vos vas a marcar la suscripción como activa. El bug clásico de SaaS vibe-coded: el modelo escribe el handler como si todo POST fuera legítimo.

Bonus: además de firma, tu handler debería ser idempotente (el mismo evento puede llegar dos veces y no debe procesarse dos veces).

4. ¿Tenés algún backup testeado, no solo automático?

Pregunta exacta: ¿alguna vez en tu vida hiciste un restore de tu base de producción a una base limpia? Si la respuesta es "no, pero Supabase/Render/Neon hace backups automáticos", tus backups no existen funcionalmente.

Un backup que nunca se restauró es una promesa, no un seguro. El día que necesites usarlo (corrupción, borrado accidental, ataque) vas a descubrir que el formato cambió, que falta el WAL, que la versión de Postgres no matchea, que pasaste el límite de retention.

5. Si mañana algo se rompe, ¿lo ves antes que el cliente?

¿Tenés un canal donde llega un alert cuando: el endpoint de checkout devuelve 500, la cola de jobs se traba, la latencia supera X, algún usuario hace login con error?

Si la respuesta es "me entero porque un cliente me escribe enojado", no tenés observabilidad. Y sin observabilidad no tenés forma de mejorar — estás reaccionando, no operando.

Las herramientas son baratas (Sentry, BetterStack, Axiom tienen tiers gratis). Lo que falta es la decisión de instrumentarlo.

¿Cómo interpretás los resultados?

El criterio es simple. Sumá las preguntas donde respondiste honestamente "no sé" o "no":

• 0 fallos: tu SaaS está mejor preparado que el 95% de los MVPs vibe-coded. Probablemente igual te falten cosas (rate limiting, validación de input, manejo de errores en el frontend) pero las críticas las cubriste.
• 1 fallo: identificá cuál es y arreglalo esta semana. No necesitás un audit profesional para esto.
• 2-3 fallos: ya tenés el roadmap. Las prioridades son obvias y no hace falta consultoría externa para el primer pase. Si querés acompañamiento, mejor un sprint de hardening que un audit.
• 4-5 fallos: estás más cerca de un Rescue que de un audit. Probablemente algo ya se rompió o está a días de romperse.

¿Necesito un audit profesional o me alcanza con esto?

Las 5 preguntas son el primer filtro. Si las respondiste con honestidad y arreglaste lo que daba, ya estás en un estado mucho mejor que el 80% de SaaS vibe-coded que están vivos hoy. Un audit profesional tiene sentido cuando:

• Querés validar que no se te escapa nada (las 5 preguntas son las críticas, no las únicas — hay otras 15-20 áreas que un audit cubre).
• Estás por levantar capital o tener un cliente enterprise que va a hacer due diligence técnica.
• Necesitás un informe escrito con priorización y estimaciones para mostrar internamente o a inversores.
• Querés un roadmap priorizado con dependencias y secuencia de implementación, no solo una lista de issues.

Pero si solo tenés MVP + 3-5 clientes piloto, hacé las 5 preguntas vos. Una tarde. Honesto. Después hablamos.