Stack y arquitectura
Qué se construye y con qué. Define todo lo que viene después.
Sin constructores visuales ni plantillas de terceros. El sitio es nuestro: se versiona, se revisa y se modifica sin depender de una licencia.
La capa que guarda, valida y conversa con los sistemas del cliente. Separada del front, para que una no arrastre a la otra.
Cada cambio de estructura es un archivo numerado que se aplica en orden. Sin esto, nadie sabe en qué estado está la base de producción.
Lo que valida el navegador es comodidad; lo que valida el servidor es la regla. Todo campo que entra se valida de nuevo del lado del servidor.
Nada sensible vive en el código. Credenciales, claves y direcciones de servicios se inyectan por fuera y nunca se versionan.
Registros legibles por máquina, no texto suelto. Es la diferencia entre encontrar un error en minutos o pasar la tarde leyendo consola.
El error clásico: las variables que el front necesita se compilan dentro del paquete al momento de construirlo. Cambiarlas en el servidor no alcanza — hay que reconstruir, o el sitio sigue apuntando al valor viejo.
Infraestructura y deploy
Dónde vive el sitio y cómo llega cada cambio hasta ahí.
Saber qué corre en cada máquina. Cuando un proyecto usa más de un servidor, confundirlos lleva a diagnosticar el problema equivocado.
Si un servicio se cae, vuelve solo. Si el servidor se reinicia, todo levanta sin intervención.
El certificado de seguridad se emite y se renueva sin que nadie se acuerde. Un certificado vencido es una caída silenciosa y evitable.
Un usuario por persona, con su propia llave. Se sabe quién entró y cuándo, y dar de baja a alguien no obliga a rotar todo.
Un sitio de una sola página responde cualquier dirección con la misma pantalla. Sin una lista explícita de rutas válidas, el servidor le dice al buscador que toda dirección inventada existe.
Los pasos exactos, en orden, con qué verificar en cada uno. Para que lo pueda correr alguien que no lo construyó.
Antes de tocar producción: leer cómo está escrito el archivo de configuración actual y respetar ese formato. Un separador equivocado puede hacer que el servidor rechace toda la configuración y deje caídos todos los sitios de esa máquina, no sólo el que se estaba tocando.
Dominios y DNS
Lo más expuesto de la puesta en producción: lo opera el área de sistemas del cliente y el efecto es inmediato y público.
Qué registros hay hoy y a dónde apuntan. Migrar sin este mapa es la forma más rápida de bajar un servicio que nadie recordaba que estaba ahí.
Cada máquina con su nombre propio, y los dominios apuntando a ese nombre. El día que cambie el servidor se toca un solo registro y no veinte.
Uno responde y el otro redirige. Que funcione sólo uno de los dos es el reclamo más común del primer día.
Sitio, landing, API y panel, cada uno con su dirección. Separados, para poder mover uno sin tocar el resto.
Se verifica después del cambio, no antes: el certificado se emite recién cuando el dominio ya apunta al servidor correcto.
Cada dirección del sitio anterior que tenga equivalente, redirigida a la nueva. Conserva el posicionamiento ganado y evita que quien tiene el enlace guardado caiga en la nada.
Si el sitio y la API están en dominios distintos, el navegador bloquea las llamadas salvo que la API lo autorice explícitamente. Cambiar un dominio sin actualizar esto deja el sitio en pie pero sin funcionar.
Antes de declarar una caída: verificar desde afuera de la red propia. Un dominio que "no anda" en una sola computadora suele ser memoria vieja del equipo o del router, no el servidor. Comprobarlo contra varios resolvedores públicos antes de mover nada en producción.
Seguridad
Lo que no se ve cuando está bien hecho. Se nota el día que falta.
Y declarado como obligatorio, para que el navegador lo exija por su cuenta en las visitas siguientes.
Impiden que el sitio se abra dentro de una página ajena, que el navegador adivine tipos de archivo y que se filtre información de navegación hacia afuera.
Todo lo que viaja al navegador es público, aunque esté escondido. Las credenciales viven en el servidor.
Distinto según el riesgo: generoso para navegar, estricto para consultar datos de personas y para intentar ingresar al panel.
Un campo invisible que una persona nunca completa. Si viene lleno, es un robot. Filtra la mayoría del spam sin molestar a nadie.
Preparada para activarse si el volumen de spam lo justifica. Se deja lista aunque arranque apagada.
Las contraseñas no se guardan nunca en texto legible. Las sesiones caducan solas.
El detalle técnico va al registro interno; la persona recibe un mensaje claro. Un error demasiado explícito le dice al atacante cómo seguir.
Base de datos y panel
El sitio junta información. Alguien tiene que poder trabajarla.
Nunca metido dentro de un texto más grande. Lo que está embebido en un mensaje no se puede filtrar, ordenar ni exportar.
De qué formulario vino. Permite separar una consulta común de un trámite con plazo legal.
Cada persona ve lo que le corresponde. Y queda registrado quién hizo cada cosa.
Quién lo atendió, cuándo y qué pasó. Sin esto, el seguimiento depende de la memoria de alguien.
Para que el equipo trabaje con la herramienta que ya usa, sin pedirle nada a nadie.
Definidos con quien va a operar el panel, no supuestos de antemano.
Se define antes de salir, no después: quién accede al panel, quién responde las consultas y quién atiende los trámites con plazo. Un formulario que registra bien pero no tiene responsable asignado es un incumplimiento esperando a ocurrir.
Integraciones
Donde el sitio deja de ser una página y pasa a ser parte de la operación.
Qué se manda, qué vuelve y qué significa cada código. Acordado con el proveedor antes de escribir una línea.
Muchos sistemas sólo aceptan llamadas desde direcciones autorizadas. Hay que pedirlo con tiempo, y verificar que el servidor salga efectivamente por la dirección declarada.
Poder trabajar y probar sin golpear el sistema real del cliente ni ensuciarlo con datos de prueba.
Y verificado explícitamente cuál está activo antes de salir. Es el error más fácil de cometer y el más difícil de notar.
Si el sistema del otro lado no responde, el sitio sigue funcionando y la persona recibe una respuesta. Nunca una pantalla colgada.
Cuando hay discusión sobre qué se mandó, la respuesta tiene que estar de nuestro lado.
Con un envío real, no sólo revisando el código. Un formulario que guarda pero no avisa parece andar hasta que alguien pregunta por qué no le llegó nada.
Lo que se generó probando queda en el sistema del cliente. Se pide darlo de baja antes de que alguien lo tome por real.
No alcanza con que el sistema del otro lado responda bien. Hay que verificar que los campos enviados queden efectivamente guardados: un servicio puede aceptar el dato, responder correctamente y después descartarlo o reemplazarlo por otro.
Medición
Lo que no se emite desde el primer día no se recupera después.
Medición de comportamiento y píxel de publicidad. Se instalan juntos, con el identificador que entrega el área de marketing.
Pantallas vistas, formulario iniciado, cada paso completado, envío final y clics de contacto. El embudo entero, no sólo el resultado.
Dónde se cae la gente. Es el dato más valioso y el que nadie pide hasta que lo ve.
Dos eventos que se disparan en el mismo momento inflan los números y hacen desconfiar de todo el tablero.
Cuando sitio y landing comparten propiedad, se separan por un campo propio en cada evento y no por la dirección.
Los parámetros con que llegó la persona se guardan y viajan hasta el registro final. Sin esto no se sabe qué campaña trajo qué.
La plataforma guarda los datos pero no los muestra en los informes hasta que se los declara. Y no recupera los días anteriores: hacerlo tarde cuesta esa información.
Sin la verificación, la atribución de campañas se degrada por las restricciones de privacidad de los teléfonos.
Qué significa cada evento y con qué nombre llega a cada plataforma. Marketing arma los tableros sin tener que preguntar.
Conviene medir de más. Activar un evento nuevo mañana no trae los datos de ayer. Emitir desde el día uno aunque no se use todavía cuesta poco y evita arrepentimientos.
Privacidad y legales
Exigible por norma, y además lo primero que mira cualquier auditoría.
Accesible desde todas las páginas y redactada sobre lo que el sitio realmente hace con los datos.
Los aporta el cliente o su área legal. Nosotros los publicamos y verificamos que el sitio cumpla lo que ahí se promete.
Hasta que la persona elija, no se mide nada. Un aviso que no frena nada es peor que no tenerlo: aparenta cumplir sin cumplir.
Y una tercera para elegir por categoría. No alcanza con un botón de aceptar y un enlace escondido.
El aviso aparece una sola vez. Un enlace en el pie permite volver a abrirlo cuando la persona quiera.
Los que la norma exige según el rubro. Probados de punta a punta: que registren y que avisen.
Casilla sin marcar por defecto, con el texto a la vista y no escondido detrás de un enlace.
Revisar que el texto legal y el sitio digan lo mismo. Si el documento promete un aviso de cookies, una casilla o un canal de contacto, el sitio tiene que tenerlo. Incumplir el propio texto publicado es peor que no haberlo escrito.
SEO e indexación
Que el sitio se encuentre, y que lo que se encuentre sea el sitio nuevo.
Distintos en cada una. Es el texto que la persona lee en los resultados antes de decidir si entra.
Imagen, título y bajada al compartir el enlace. Sin esto, el enlace aparece como texto pelado y pierde clics.
Con el panel, la API y los archivos internos excluidos. Lo privado no se indexa.
Sólo las que existen. Un mapa con direcciones muertas le resta confianza al sitio entero.
Que se vea bien es lo de menos: el buscador lee el código de respuesta, no el texto. Una página de error que responde "todo bien" no sirve.
Pestaña, favoritos y pantalla de inicio del teléfono.
La imagen principal es lo que más pesa y lo primero que se ve. Comprimirla bien cambia la percepción de velocidad del sitio entero.
Permite pedir revisión en lugar de esperar, ver qué quedó indexado y conocer con qué búsquedas llega la gente. Conviene darla de alta con una cuenta institucional y no personal.
Después de reemplazar un sitio, el buscador sigue mostrando enlaces internos del anterior durante una a tres semanas. Las redirecciones y los errores correctos resuelven esto solos; la consola de búsqueda sirve para acelerarlo.
Salida y respaldo
El día de la salida no se improvisa.
Con su resultado. Se sale a producción porque las pruebas dieron bien, no porque llegó la fecha.
Qué se hace para dejar todo como estaba, paso por paso. Escrito antes de salir, cuando todavía se piensa con calma.
Los cambios de dominio se hacen en llamada con quien administra el DNS, no por mensajes. Resuelve en minutos lo que de otro modo lleva días.
Cada dominio, cada certificado y un recorrido completo del formulario principal. Antes de avisar que está listo.
Si hubo caídas, se informan con el dato exacto y qué las causó. La transparencia acá vale más que el minuto perdido.
Un respaldo que nunca se probó no es un respaldo. Se restaura una vez para confirmar que sirve.
Qué salió, qué pasó, qué queda pendiente de cada lado y qué sigue. El mismo día.
Lo que no entró en esta etapa, en el tablero y con dueño. Lo que no queda escrito se pierde.