Plataformas de producto y SaaS

El expediente empieza con una persona, una tarea recurrente y una consecuencia real, no con una ficha de persona genérica. Quien compra, quien usa, quien administra, quien presta soporte y quien autoriza el gasto pueden ser actores distintos. Documentamos soluciones actuales, intentos fallidos, frecuencia, urgencia, coste de cambio y el momento en que aparece el primer valor. Una entrevista, un ticket de soporte, la analítica, una fuente de mercado y el criterio comercial no prueban lo mismo. Cada supuesto conserva su procedencia y grado de confianza; una convicción del fundador puede orientar la investigación, pero no presentarse como demanda validada.

El contrato de producto separa el resultado buscado de la lista de funcionalidades acumulada. Define el trabajo principal, el menor recorrido coherente, los controles administrativos imprescindibles, las obligaciones sobre los datos y la evidencia que se buscará tras el lanzamiento. Un MVP no es automáticamente toda la hoja de ruta ni un prototipo desechable. Es una versión delimitada, útil y segura para el grupo invitado, creada para responder preguntas concretas. Una petición sin decisión, responsable o criterio de aceptación se mantiene en el registro de oportunidades en vez de entrar en desarrollo por inercia.

La realidad comercial forma parte de la arquitectura. El modelo de precio, la estructura de cuentas, los derechos de cada plan, el soporte esperado, la captación, el traspaso desde ventas y las decisiones técnicas sensibles al coste modifican el producto razonable. La propuesta enumera superficies, roles, entornos, integraciones, volumen de migración, idiomas y límite de publicación. NobleJackal puede reducir incertidumbre y entregar el sistema contratado, pero no garantiza encaje producto-mercado, adopción, retención, escala, ingresos o inversión. Esos resultados dependen también del mercado, la oferta, el equipo y la operación.

Traducimos el producto a dominios, registros, reglas y límites de responsabilidad. Se determina qué fuente es autoritativa, cómo cambian los estados, qué debe poder auditarse y dónde un fallo afecta a dinero, acceso, privacidad o continuidad. La multitenencia es una decisión de negocio, riesgo y operación, no solo un patrón de base de datos. Los modelos compartido, aislado e híbrido implican diferencias de aislamiento, coste, personalización y mantenimiento. La opción y sus excepciones quedan registradas, incluida cualquier exigencia particular de región, cifrado, conservación, rendimiento o despliegue.

El contexto del tenant debe viajar con la identidad y aplicarse en cada capa relevante. Registro, invitaciones, autenticación, sesiones, asignación de roles, autorización, administración privilegiada, acceso de soporte e identidades de servicio se diseñan como controles conectados. Estar autenticado no demuestra permiso para leer o modificar un recurso. Se comprueban tenant, cuenta, rol, objeto y acción; también se ensaya expresamente la denegación entre tenants. Los eventos de auditoría muestran quién actuó, para qué tenant, por qué ruta y con qué resultado, sin convertir datos sensibles en un archivo de logs sin gobierno.

El contrato de datos cubre recogida, clasificación, procedencia, validación, residencia, conservación, borrado, exportación, copia y recuperación. También identifica quién puede corregir o aprobar datos con consecuencias y qué ocurre cuando una integración cae o duplica mensajes. Planes, entitlements, límites de consumo, estados de facturación, webhooks, API y conectores son comportamiento versionado del producto, no detalles para después. La interpretación jurídica y regulatoria corresponde a los asesores cualificados del cliente; la ingeniería implementa el requisito aprobado y declara lo que realmente se ha probado, sin promesas genéricas de cumplimiento.

El mapa de experiencia empieza antes del acceso y continúa más allá de la tarea principal. Evaluación, elección de plan, invitación, onboarding, activación, uso diario, colaboración, avisos, facturación, soporte, baja y salida de datos se consideran en la medida del producto contratado. Distinguimos qué debe comprender una persona nueva, qué puede aprender en contexto y cuándo una ayuda humana es más responsable que otra pantalla. La activación es un resultado útil propio del producto, no un evento universal. Completar una lista guiada solo importa si acerca a la persona al trabajo que vino a realizar.

Los flujos se especifican con permisos y estados, no como una secuencia de pantallas ideales. Los estados vacío, carga, parcial, inválido, denegado, caducado, duplicado, sin conexión y destructivo reciben texto real y una recuperación segura. El sistema de diseño enlaza componentes, reglas editoriales, interacción, geometría adaptable y accesibilidad para que el equipo pueda ampliar sin inventar otro dialecto. Teclado, foco, contraste, etiquetas, asociación de errores, zoom, movimiento reducido y comportamiento de derecha a izquierda, cuando proceda, forman parte de la aceptación y no de una revisión estética tardía.

Un prototipo responde una incertidumbre concreta antes de comprometer código de producción. El de concepto puede comprobar lenguaje y orden; el interactivo, una tarea; y una prueba técnica, una integración o un riesgo de rendimiento. Cada hallazgo se vincula a la decisión que informó, con las limitaciones de muestra y contexto. El texto de producto evita seguridad fingida, patrones oscuros y condiciones escondidas. Plan, prueba, renovación, cancelación, uso de datos y acciones irreversibles deben entenderse cuando se decide. Los idiomas se diseñan como estados propios del producto, no como traducciones pegadas que rompen sentido y maquetación.

La arquitectura sigue la carga, el riesgo y el equipo acordados, no el diagrama de moda. Elegimos límites para aplicación, servicios, colas, almacenamiento, búsqueda, ficheros, analítica e integraciones con preferencia por la estructura más sencilla que cumpla la aceptación actual. Los contratos API definen autenticación, autorización, esquemas, idempotencia, paginación, errores, límites y versionado. Los cambios de base y las migraciones tienen compatibilidad, verificación y vuelta atrás. Los presupuestos de rendimiento cubren recorridos cuyo retraso perjudica activación, trabajo o administración, no solo una puntuación sintética de portada.

El desarrollo seguro es una exigencia continua. El modelado de amenazas identifica activos, actores, fronteras de confianza, abusos y controles. Secretos, dependencias, artefactos de compilación, entornos y accesos privilegiados tienen reglas y responsables. Entradas, salidas, sesiones, aislamiento entre tenants y acciones sensibles se prueban contra el objetivo acordado. La automatización reduce riesgo repetible, pero no certifica que el producto sea seguro. Una revisión independiente, un pentest o una evidencia formal de cumplimiento solo se incluyen cuando la propuesta nombra versión del estándar, alcance, proveedor, entorno y criterio de aceptación.

La observabilidad se diseña alrededor del impacto sobre producto y tenant. Logs, métricas y trazas comparten identificadores que permiten a un operador autorizado seguir una solicitud sin exponer información personal o confidencial innecesaria. Antes del lanzamiento se eligen objetivos de servicio, presupuesto de error, salud de dependencias, retraso de colas, trabajos fallidos, errores de derechos o cobro y síntomas de recorridos críticos. Una versión pasa por entornos controlados, cambios revisados, pruebas representativas, ensayo de migración, controles de función cuando son útiles y rollback. Que el pipeline esté en verde no basta: los recorridos contratados se verifican en producción.

La preparación alinea la comunicación del producto con la realidad de producción. Los planes y derechos, el onboarding, los canales de soporte, el estado del servicio, los textos jurídicos y de privacidad, la ayuda de administración y los runbooks internos deben describir la misma oferta. Se ejercitan aprovisionamiento de tenants, invitaciones, importaciones, eventos de facturación, entrega de correo, avisos e integraciones críticas con cuentas representativas. El equipo acuerda severidades, escalado, comunicación al cliente y quién puede desactivar una función o restaurar el servicio. El lanzamiento puede ser gradual si el riesgo o la capacidad de soporte hacen irresponsable una exposición total.

La medición posterior vuelve al contrato de decisión. Observamos activación, tarea completada, fallos, demanda de soporte, señales de retención, coste y cualificación comercial mostrando los límites de cada fuente. La telemetría no explica por sí sola el motivo, y una solicitud no se convierte automáticamente en prioridad. El responsable de producto sopesa evidencia, encaje estratégico, alcance, consecuencia, esfuerzo y riesgo. Feature flags, experimentos e instrumentación temporal reciben propietario y fecha de retirada para que no se transformen en ramas permanentes y desconocidas.

La entrega identifica la titularidad pactada de código, repositorios, diseños, dominios, datos, infraestructura, cuentas, licencias, documentación y componentes de terceros. Incluye instrucciones de entorno y publicación, registros de arquitectura y decisión, límites conocidos, hallazgos de seguridad, procedimientos operativos y backlog aceptado. Soporte, hosting, monitorización, respuesta a incidentes, evolución y operaciones cloud solo continúan si se contratan por separado. NobleJackal puede asumir esa responsabilidad mediante un modelo de servicio escrito; el proyecto inicial de 20.000 USD no genera una obligación indefinida de soporte.