Qué posees realmente cuando el proyecto termina

Hay una pregunta que casi nadie hace antes de firmar, y determina cuánto control tendrás durante toda la vida de lo que estás comprando. Cuando esto esté terminado, ¿qué es mío?

Importa sobre todo en el peor momento. Si la relación acaba mal, si el estudio cierra, o si simplemente quieres trabajar con otra gente, la respuesta determina si eso es una molestia o una catástrofe.

El dominio es el que arruina a la gente

Tu nombre de dominio debe estar registrado en una cuenta que sea tuya, con tu correo electrónico y pagada con tu tarjeta.

Es la trampa más habitual del sector y normalmente no es malintencionada. El estudio registra el dominio durante la puesta en marcha porque es más rápido que esperar a que lo haga el cliente, todo el mundo sigue con el proyecto y nadie vuelve a pensar en ello. Dos años después el cliente quiere marcharse y descubre que la dirección que conocen sus clientes, la que lleva en la furgoneta, en las tarjetas y en todas las facturas que ha emitido, es legalmente propiedad de otra persona.

Un estudio que colabora la transfiere en una tarde. Uno que no colabora o al que no se puede localizar te deja casi sin opciones, porque un dominio no es algo que se pueda reconstruir. Todo lo demás en esta página se puede recrear con tiempo y dinero. Tu dominio no.

Compruébalo hoy, sea quien sea quien te hizo la web. Entra en el registrador. Si no puedes, esa es la respuesta.

El código

En desarrollo a medida, el código fuente debe ser tuyo sin matices, y el contrato debe decirlo con palabras en lugar de dejarlo a la suposición.

Conviene entender dos distinciones. El código fuente es lo que edita un programador. El código desplegado es lo que ejecuta el servidor, que en muchas pilas es una versión compilada o empaquetada, técnicamente presente pero prácticamente inservible para hacer cambios. Que te entreguen lo segundo y te digan que tienes el código no es lo mismo.

La otra distinción separa lo que se construyó para ti de aquello con lo que se construyó. Los frameworks, las bibliotecas y los componentes de código abierto no son tuyos y no hace falta que lo sean; están libremente a disposición de cualquiera, incluida la persona que contrates después. Lo que importa es que la parte escrita específicamente para tu proyecto te pertenezca, sin restricciones sobre quién puede editarla más adelante.

Si un estudio usa un framework propio y cerrado o un constructor de páginas con licencia por sitio, pregunta directamente qué pasa con tu web si dejas de trabajar con ellos. Hay respuestas honestas a esa pregunta. También hay estudios cuyo modelo de retención se basa por completo en que la respuesta sea mala.

La cuenta de alojamiento

Mismo principio que el dominio, con algo menos en juego.

Si tu web está alojada en la cuenta del estudio, no puedes moverla, no ves la factura, y si su cuenta tiene un problema tu web tiene un problema. Lo ideal es que el alojamiento esté a tu nombre y tú concedas acceso. Dicho esto, es realmente negociable: el alojamiento incluido es un servicio normal y legítimo, y para un negocio sin nadie técnico puede ser exactamente el acuerdo adecuado. Solo es un problema cuando nadie te lo ha contado.

Nosotros alojamos proyectos en nuestra propia infraestructura dentro de un plan de mantenimiento, y creemos que es un buen trato para el cliente adecuado. Eso no cambia quién posee el dominio ni el código, y tampoco debería cambiarlo para nadie más.

Las cuentas de alrededor

La lista que se olvida. La analítica, la pasarela de pago, el servicio de correo, las herramientas para webmasters, los perfiles sociales creados en el lanzamiento, el certificado SSL si no es automático y cualquier tercero del que dependa la web.

Cada una de ellas debe estar en una cuenta que controles, con tu correo de recuperación. Acceso concedido al estudio, no propiedad en manos del estudio. Es la misma corrección en cada caso y lleva minutos al configurarlo, que es exactamente por lo que merece la pena insistir al configurarlo en lugar de desenredarlo después.

Los datos

Tus fichas de clientes, pedidos, consultas, reservas y tu lista de correo son tuyos y, en un sentido importante, de las personas que describen.

Deberías poder exportarlo todo en un formato que otra cosa sepa leer. Pregúntalo antes de firmar, no después. Un sistema del que no puedes sacar tus datos es un sistema del que nunca podrás salir, y a veces eso es un diseño deliberado y no un descuido.

La prueba

Olvida la redacción del contrato y haz una sola pregunta. Si mañana contrataras a otro desarrollador, ¿qué necesitarías de nosotros y podrías conseguirlo sin nuestra colaboración?

Si la respuesta honesta es que podrías entregarle a alguien las credenciales del dominio, el acceso al alojamiento, el código y una exportación de la base de datos, y que esa persona podría continuar, entonces posees tu proyecto. Si la respuesta pasa por que nosotros estemos de acuerdo, no lo posees, diga lo que diga la factura.

Por qué organizamos así nuestro trabajo

Nuestros proyectos a precio cerrado son exactamente eso: tú lo posees y tú lo operas, sin cuota recurrente, y el trabajo posterior se presupuesta cuando lo quieras. Nuestro plan de mantenimiento nos mantiene alojando y cuidando la cosa, mes a mes, mientras siga funcionando.

Si separamos según quién lo opera en lugar de según cómo pagas, es porque la segunda fórmula fomenta discretamente la trampa descrita más arriba. Cuando el ingreso recurrente depende de que el cliente no pueda marcharse, el incentivo es poner difícil marcharse. Cuando depende de hacer un mantenimiento que si no tendría que hacer él, el incentivo es merecer que te conserven.

En ambos casos deberías seguir siendo dueño de tu dominio y de tu código. Si alguna vez un estudio te dice lo contrario, esa es toda la respuesta sobre ese estudio.