Romana
English
Francais
Deutsch
EspanolEl punto de partida
OmniWatchGuard crecio rapidamente a lo largo de unos meses — nuevas funciones, nuevas paginas, nuevo contenido en cada sprint. En un momento dado me di cuenta de que ya no sabia con certeza, sin revisar el codigo, que afirmaciones del sitio eran ciertas y cuales seguian de la fase de planificacion.
No fue una decision deliberada de mentir. Es el tipo de discrepancia que surge de forma natural en un producto de un solo fundador: escribes el texto para una funcion antes de construirla, la pones en la hoja de ruta, y luego, en la prisa por lanzar otras cosas, el texto permanece sin cambios durante meses.
El resultado de la auditoria ahora se refleja directamente en el producto — consulta losplanes actualeso prueba gratis para ver exactamente que esta implementado, no lo que prometia el texto antiguo.
El proceso: como encontramos las discrepancias
No partimos de una lista de sospechas. Partimos de una pregunta simple:cada archivo que genera contenido publico — paginas, componentes de FAQ, esquema JSON-LD, la calculadora de precios — corresponde a lo que existe realmente en el codigo?
- Enumeramos todos los archivos que producen contenido visible para el usuario o los motores de busqueda:
FAQ.astro,FAQSchema.astro,FAQEnterprise.astro,PricingSchema.astro,Comparison.astro,Calculator.astro,SoftwareAppSchema.astro,AggregateRatingSchema.astro,privacy.astro - Para cada afirmacion de funcionalidad ("soporta X", "monitoriza Y"), buscamos la implementacion real en el backend/crawler
- Clasificamos cada afirmacion en tres categorias: verdadera (implementada y probada), parcialmente verdadera (implementada pero con limitaciones no mencionadas), falsa (solo en la hoja de ruta o nunca construida)
- Para cada afirmacion falsa o parcial, elegimos una de dos acciones: corregir el texto para reflejar la realidad, o construir la funcion para que se vuelva verdadera
Que encontramos
Valoraciones y testimonios codificados directamente
AggregateRatingSchema.astro y Testimonials.astro tenian una valoracion fija de 4,9, un numero fijo de "200+ resenas" y "500+ empresas", ademas de nombres y citas de testimonios escritos directamente en el codigo — esos clientes no existian. Sustituimos todo por datos reales, calculados a partir de la tabla reviews de la base de datos: valoracion media y numero real de resenas, la seccion de testimonios se oculta sola si aun no existe ninguna resena real. El CTA "deja una resena" permanece visible de forma permanente.
Funciones en la hoja de ruta presentadas como activas
La monitorizacion de paginas con inicio de sesion, el RBAC (roles y permisos) y el SSO aparecian en la FAQ y en la tabla comparativa como funciones disponibles. No lo eran. Corregimos los seis archivos afectados (FAQ, FAQSchema, PricingSchema, Comparison, Calculator, SoftwareAppSchema) para mostrar claramente "Hoja de ruta 2026" para RBAC/SSO, y eliminamos por completo la afirmacion sobre aplicaciones iOS/Android que no existian ni estaban planificadas.
Error de visualizacion que ocultaba un problema real
El componente Comparison.astro de la pagina de inicio tenia un error de renderizado que mostraba una marca verde (✓) para cualquier funcion, independientemente de los datos reales subyacentes — incluidas funciones que tenia la competencia y nosotros no. En la practica, la tabla comparativa mentia por un error tecnico, no solo por texto desactualizado.
| Que encontramos | Antes | Despues |
|---|---|---|
| Valoracion y testimonios | Codificados, falsos | De la base de datos real, se ocultan si no hay datos |
| Monitorizacion de paginas con login | Presentada como activa | Corregida a "Hoja de ruta 2026", luego construida realmente |
| RBAC / SSO | Presentado como activo | Marcado claramente como "Hoja de ruta 2026" |
| Aplicaciones iOS/Android | Mencionadas | Eliminadas — no existen, no estan planificadas |
| Tabla comparativa | Error: mostraba ✓ para todo | Corregido, refleja datos reales |
Por que elegimos construir la funcion, no solo corregir el texto
Para la monitorizacion de paginas con inicio de sesion, teniamos que elegir: corregir el texto (rapido, una hora de trabajo) o construir realmente la funcion (mas esfuerzo, pero resuelve el problema de raiz). Elegimos la segunda opcion. Anadimos una columna cifrada (AES-GCM) para la cookie/cabecera de autenticacion en la tabla de monitores, el crawler descifra e inyecta la cabecera en ambas rutas de obtencion (simple y Puppeteer), y detecta la expiracion de sesion mediante un codigo 401/403 o una redireccion a una pagina de inicio de sesion. Lo probamos de extremo a extremo en el propio panel de OmniWatchGuard (que usa Authorization: Bearer, no cookie) antes de volver a publicar el texto como verdadero.
Lo que quedo sin cambios
No todo lo que encontramos incompleto se corrigio construyendolo. RBAC y SSO permanecen en una hoja de ruta real para 2026 — estan marcados como tal, sin ambiguedad, y no prometemos una fecha exacta hasta que empecemos realmente a trabajar en ellos.
Preguntas frecuentes
Por que publicais esto en lugar de corregirlo en silencio?
Porque el proceso en si es util para otros fundadores en solitario que se enfrentan a la misma discrepancia natural entre la hoja de ruta y el texto de marketing, y porque la transparencia sobre lo que es verdad hoy genera mas confianza que cualquier testimonio.
Como evitais que se repita el mismo problema?
Todavia no existe un proceso automatizado que evite por completo la discrepancia — es un riesgo estructural en cualquier producto con iteracion rapida. Lo que ha cambiado concretamente: las valoraciones y testimonios ya no pueden codificarse directamente (provienen exclusivamente de la base de datos), y cualquier funcion nueva mencionada en el texto pasa por una verificacion manual frente al codigo antes de publicarse.
La auditoria tambien cubrio las paginas en ingles?
Si, todas las correcciones se aplicaron simetricamente en las versiones RO y EN de cada archivo afectado, incluido el esquema JSON-LD utilizado por los motores de busqueda.