Qué preguntar antes de contratar a alguien para que te haga la web (y por qué importa)

Hay una conversación que casi nunca ocurre antes de firmar una web. La conversación donde el cliente pregunta lo importante y el proveedor contesta sin rodeos. En su lugar suele pasar otra cosa: una propuesta con precio, una pregunta sobre el plazo, un correo de confirmación, y a firmar.

Meses después, cuando algo se tuerce (quieres cambiar de proveedor, mover la web a otro hosting, recuperar tus datos, o simplemente entender qué has comprado), aparecen las preguntas que nadie hizo a tiempo.

Este artículo es esa conversación. Las preguntas que deberías hacer antes de contratar a alguien para que te haga la web. No para parecer experto, ni para regatear. Para tomar una decisión informada sobre algo que va a sostener tu negocio en internet durante años.

Por qué casi nadie pregunta lo importante

El problema no es que los clientes sean ingenuos. Es que el sector no facilita las preguntas correctas.

La mayoría de proveedores web venden el "qué" sin explicar el "cómo". Te enseñan capturas bonitas, te hablan de SEO, te muestran ejemplos de otros clientes. Pero rara vez te explican qué tecnología van a usar, qué pasa si dejas de trabajar con ellos, o dónde van a vivir tus datos. Y tampoco les conviene que preguntes, porque las respuestas honestas suelen complicar la venta.

Y por el otro lado, el cliente medio no tiene contexto técnico para hacer las preguntas correctas. No por incapacidad, sino porque nunca antes había contratado una web. Es como si compraras tu primer coche sin saber que existen los seguros, las revisiones, o las garantías. Pagas, conduces, y cuando algo falla descubres lo que no preguntaste.

Las preguntas de este artículo no son técnicas. Son preguntas de negocio formuladas en lenguaje claro. Cualquiera puede hacerlas. Y lo que importa no es solo la respuesta que recibas, sino cómo te la den. Una respuesta directa y honesta vale más que una respuesta perfecta llena de promesas.

Bloque 1 — Propiedad: ¿qué compras exactamente?

1. "¿De quién es el código de la web?"

Hay tres respuestas posibles. Solo una te conviene.

La primera: "el código es tuyo". Significa que tras el pago, el código fuente queda bajo tu titularidad y te lo pueden entregar en cualquier momento. Es lo que firmarías si compraras cualquier otro activo de tu empresa.

La segunda: "el código lo retenemos nosotros, tú pagas por usarlo". Es un modelo SaaS legítimo, pero deberías saberlo desde el principio. Lo que estás contratando no es una web, es un servicio mensual. El día que dejes de pagar, dejas de tener web.

La tercera: la respuesta evasiva. "Eso se ve después", "depende del proyecto", "no es algo que se hable normalmente". Esa respuesta es la respuesta. Significa que no tienes el código y que probablemente nunca lo vas a tener.

Pregunta esto al principio. No al final, cuando ya estés decidido.

2. "¿De quién es el diseño?"

Igual que el código, el diseño es un entregable. Si pagas por una identidad visual, la titularidad debería quedar reflejada por escrito tras el pago. Esto incluye el logo, los colores, la tipografía, las maquetas, y los archivos editables (no solo el PNG final, sino el archivo de Figma o el SVG vectorial).

Si en algún momento decides rediseñar la web con otro proveedor, deberías poder darle los archivos originales a quien venga después. Si no puedes, vas a tener que pagar el diseño otra vez. Y otra vez. Cada vez que cambies.

3. "¿Dónde se almacenan mis datos y de quién son?"

Esta es la pregunta que más raramente se hace y la que más caro sale no hacer.

Los datos son los leads que llegan por el formulario, los pedidos de la tienda, los suscriptores del blog, las facturas, las visitas, los clientes que se registran. Toda la información que se acumula a medida que la web funciona. Y esa información tiene valor real para tu negocio.

Lo que necesitas saber: dónde se guardan físicamente (en qué proveedor de hosting o de base de datos), bajo qué cuenta (la tuya o la del proveedor), y cómo puedes exportarlos si lo necesitas. Si la respuesta es "están en nuestra base de datos, ya te lo gestionamos nosotros", lo que te están diciendo es que tus datos viven en su cuenta. Si esa cuenta desaparece, tus datos también.

Hay matices. Una pyme pequeña no necesita gestionar su propio servidor de bases de datos. Eso lo puede hacer el proveedor. Lo que sí necesita es que la cuenta esté a su nombre, o al menos que pueda mover los datos a su propia cuenta cuando quiera. Sin pagar un extra. Sin pedir permiso.

Bloque 2 — Portabilidad: ¿qué pasa si te quieres ir?

4. "¿Qué pasa si quiero cambiar de proveedor dentro de dos años?"

Esta pregunta es el test más limpio. La respuesta te dice más sobre el contrato que cualquier cláusula.

Si la respuesta es "te entregamos el código, los datos exportados y la documentación", estás contratando algo portable. Una decisión que puedes revisar sin penalización.

Si la respuesta es "se podría hacer, pero requiere un trabajo de migración que se factura aparte", lo que te están diciendo es que la salida tiene un coste y probablemente sea alto. No es necesariamente malo, pero deberías saber cuánto antes de firmar.

Si la respuesta es "es complicado", "tendríamos que ver", o un silencio incómodo, ya tienes tu respuesta.

5. "¿Mi web depende de algún sistema cerrado que solo tú puedas mantener?"

Aquí entran los plugins propietarios, los temas comprados a medida, las integraciones hechas con código que no se documenta, o las webs construidas sobre plataformas cerradas que nadie más conoce.

Si tu web está construida sobre estándares (HTML, CSS, JavaScript, una base de datos relacional estándar, un framework moderno como Next.js o Astro), cualquier desarrollador competente podrá entenderla, modificarla, o migrarla. Si está construida sobre un sistema propietario, solo el proveedor que la hizo podrá tocarla. Y eso es atadura, aunque no lo llamen así.

No es que todos los sistemas propietarios sean malos. Algunos resuelven problemas reales. Pero el cliente tiene derecho a saber que está atado antes de firmar, no después.

Bloque 3 — Tecnología y mantenimiento

6. "¿Qué tecnología vas a usar y por qué?"

No necesitas entender la respuesta a fondo. Pero necesitas que te la den.

Un buen proveedor te dirá algo como "vamos a usar Next.js porque es un framework moderno, mantenido por una empresa grande, con comunidad amplia, y que dentro de cinco años va a seguir siendo una opción razonable". O te dirá "vamos con WordPress porque tu equipo ya lo conoce, hay miles de plugins, y para lo que necesitas es suficiente". Las dos respuestas son válidas según el contexto.

Lo que no debería pasar es que te respondan "no te preocupes por eso, eso es lo nuestro". Esa frase oculta dos cosas: o bien no quieren explicártelo porque la respuesta es incómoda (una tecnología obsoleta, un sistema propietario, una solución que les ata a ellos), o bien no respetan tu derecho a entender qué estás comprando.

Pregunta también si la tecnología sigue manteniéndose activamente. Una web construida sobre un framework que ya no recibe actualizaciones es una bomba de relojería de seguridad. Tarde o temprano alguien encuentra una vulnerabilidad y nadie la arregla.

7. "¿Quién la mantiene una vez entregada, y qué incluye exactamente ese mantenimiento?"

Mantenimiento es una palabra que significa cosas muy distintas según quién la diga.

Para algunos proveedores, mantenimiento es "te respondo el correo si algo se rompe". Para otros, es "te actualizo los plugins una vez al mes y te hago una copia de seguridad". Para otros, es "te monitorizo la web 24/7, te aplico parches de seguridad, te resuelvo cualquier incidencia en X horas, te envío un informe mensual y te incluyo Y horas de cambios menores al mes".

Las tres son mantenimientos legítimos. Pero cuestan precios muy distintos y dan tranquilidades muy distintas. Antes de firmar, pide por escrito qué incluye el mantenimiento mensual, qué no incluye, cuál es el tiempo de respuesta ante incidencias, y cuánto cuesta cualquier cambio fuera de lo incluido.

Bloque 4 — Proceso y entregables

8. "¿Qué me vas a entregar y en qué momento?"

Pide hitos concretos. No "una web bonita en dos meses". Sino: "en la semana 3 te entrego las maquetas de las páginas principales, en la 5 te enseño la web navegable en un entorno de pruebas, en la 7 cerramos contenido y en la 8 la lanzamos". O similar.

Esto importa por dos razones. La primera: te da visibilidad sobre el progreso real. Vas a poder corregir cosas pronto, cuando todavía es barato hacerlo. La segunda: te protege. Si el proyecto se eterniza, vas a saber en qué punto se atascó y por qué.

Y al final del proyecto, deberías recibir un paquete claro: la web funcionando, el código, los datos de acceso (no compartidos con el proveedor, los tuyos), la documentación básica, y los archivos del diseño. Si te entregan solo "la web funciona, ya está", estás recibiendo la mitad de lo que pagaste.

9. "¿Cómo gestionas los cambios que pida durante el proyecto?"

Todo proyecto web tiene cambios. Lo que cambia es cómo los gestiona cada proveedor.

Algunos los incluyen sin discutir y se quejan en privado de que el proyecto se ha desbordado. Otros los facturan aparte sin avisar y te llega una sorpresa en la factura final. Los mejores te dicen al principio: "cambios menores incluidos hasta X horas, cambios mayores se evalúan y se presupuestan antes de hacerse". Eso es lo que quieres oír.

Si no hay reglas claras sobre cambios, va a haber fricción. Es matemática.

Cómo distinguir una respuesta real de una evasiva

Después de hacer estas preguntas, presta atención a la forma de la respuesta, no solo al contenido.

Una respuesta real suele ser concreta. Tiene nombres propios (de tecnologías, de proveedores, de procesos), tiene números (de horas, de plazos, de precios), y reconoce limitaciones. Suena algo así: "usamos Next.js con Supabase, el código se entrega en GitHub al cierre del proyecto, el mantenimiento mensual son 80€ e incluye estas cinco cosas, los cambios mayores se presupuestan aparte. Si dentro de dos años quisieras irte, el código es tuyo y puedes contratar a cualquiera para que lo mantenga".

Una respuesta evasiva es lo contrario. Es vaga, llena de promesas generales, evita los detalles concretos, y desplaza las decisiones difíciles hacia el futuro. Suena algo así: "tranquilo, eso se ve, normalmente no es problema, ya iremos viendo cada caso". Cada "ya veremos" es una decisión que estás dejando en manos del proveedor para más adelante. Cuando llegue ese más adelante, lo más probable es que ya no tengas margen de negociación.

Y si las respuestas son honestas pero te dejan ver que estás contratando algo que no encaja con lo que tu negocio necesita (un sistema cerrado, un mantenimiento mínimo, una tecnología que no entiende nadie más), también es información útil. Sabrás dónde estás antes de firmar, no después.

Antes de firmar, una última cosa

Una web no es un entregable puntual. Es una infraestructura de tu negocio que va a evolucionar durante años. Y la calidad de la relación con quien la construye importa tanto como la calidad del producto en sí.

Si las preguntas honestas hacen que el proveedor se incomode, que las esquive, o que te diga que estás complicando algo simple, esa relación ya está marcada. No va a mejorar después del contrato. Va a empeorar.

Pero si las preguntas honestas se reciben con respuestas claras, con tiempo dedicado a explicarte cada matiz, con la disposición a poner por escrito lo que se acuerda, esa es la relación que quieres. Aunque el presupuesto sea un poco más alto. Aunque el plazo sea un poco más largo.

Una web bien construida te ahorra dinero durante años. Una web mal construida te lo cobra en silencio durante el mismo tiempo.

Si quieres revisar estas preguntas aplicadas a tu caso concreto, escríbeme. Una conversación de 30 minutos. Me cuentas qué proveedor estás valorando, qué te están proponiendo, y te ayudo a leer entre líneas. Sin compromiso, sin propuesta de servicios al final. Una segunda opinión informada antes de firmar.