Qué exigir en un presupuesto digital para no llevarte sorpresas

Un presupuesto de 18.000 € para rehacer una tienda con 3.000 referencias cabe en una hoja. Lo he visto muchas veces: tres líneas de concepto, un total, un 40 % a la firma. Y la discusión de verdad —quién se queda el código, quién puede tocar el servidor, qué pasa si en marzo el checkout falla— llega ocho meses después, por email, con el catálogo caído y dos partes convencidas de tener razón.

El presupuesto es el único momento en el que tienes poder de negociación real. Después ya has pagado, ya tienes medio proyecto hecho y cambiar de proveedor cuesta más que tragar. Así que lo que no esté escrito ahí, no existe. Esta es la lista de lo que tiene que estar, y el porqué de cada punto.

Alcance: qué se entrega, en qué formato y cuándo se considera terminado

La mayoría de los conflictos no son por mala fe. Son porque «migración del catálogo» significa una cosa para ti y otra para quien lo escribió. Tú entiendes que las 3.000 fichas llegan con sus descripciones, sus atributos, sus imágenes optimizadas y sus redirecciones desde las URLs viejas. Él entiende que se vuelca un CSV con nombre, SKU y precio, y que las fotos las subes tú.

Lo que tiene que aparecer por escrito:

• Lista de entregables numerada. No «web corporativa», sino cuántas plantillas de página, cuántos idiomas, qué pasarelas de pago, qué integraciones con qué sistemas y en qué dirección van los datos.
• Qué queda explícitamente fuera. Esta es la parte que casi nadie pide y la que más dinero ahorra. Un párrafo de «no incluye» evita el 80 % de las discusiones de ampliación.
• Criterio de aceptación. Qué tiene que pasar para que el proyecto esté terminado. Idealmente una lista de pruebas: se hace un pedido real con tarjeta, se sincroniza con el ERP (el sistema que lleva stock, pedidos y facturación), se genera la etiqueta de envío, se devuelve el pedido y el stock vuelve. Si no hay criterio de aceptación, «terminado» es cuando el proveedor decide que lo está.
• Contenidos y datos: quién los prepara. El motivo número uno de retraso en proyectos de e-commerce no es el desarrollo, son las fichas de producto que el cliente tenía que mandar en dos semanas y manda en tres meses.

De quién es el código

Aquí hay tres situaciones distintas y conviene no confundirlas.

Uno: desarrollo a medida. Módulos, temas, integraciones escritas para ti. Por defecto, en España, los derechos de explotación de una obra por encargo no se te transmiten automáticamente por el hecho de pagar la factura: hace falta que esté escrito. Lo que necesitas es una cesión en exclusiva de los derechos de explotación, para cualquier soporte, sin límite territorial y por el máximo plazo legal. Una frase. Si no está, el proveedor podría reutilizar, licenciar o simplemente negarte el permiso para que otro lo modifique.

Dos: software de terceros con licencia. El tema de pago que han comprado, el módulo de facturación, el conector de la agencia de transporte. Eso no te lo pueden ceder porque no es suyo. Lo que sí puedes exigir es que las licencias estén compradas a nombre de tu empresa, no a nombre de la agencia. Es una diferencia enorme: si están a su nombre, el día que os separéis pierdes las actualizaciones y el soporte, y a veces la licencia misma.

Tres: herramientas propias de la agencia. Muchos estudios tienen su framework, su base de plantillas, su librería interna. Es legítimo y suele abaratar el proyecto. Pero tiene que estar declarado, y tiene que venir con una licencia perpetua, irrevocable y transferible para usarla y modificarla, incluso si dejas de ser cliente. Si te dicen que no, no es necesariamente una estafa: es un modelo de negocio. Pero tú tienes que saberlo antes de firmar, porque significa que salir de ahí implica rehacer.

Lo que no está escrito en el presupuesto no se negocia después: se pierde.

Y una contrapartida honesta: no siempre te interesa la propiedad del código. Si montas la tienda sobre Shopify con un tema estándar y tres apps, no hay «código tuyo» que reclamar, y probablemente eso sea lo correcto para tu volumen. La propiedad del código importa cuando hay desarrollo a medida significativo —integraciones con tu ERP, lógica de precios, un configurador— y cuando ese desarrollo representa una parte real de tu factura. Pedir la cesión de derechos de una tienda de 4.000 € hecha con plantilla es ruido.

Cuentas, accesos y credenciales: el punto que más caro sale

El código se puede rehacer. Un historial de campañas de tres años, no. Un dominio secuestrado te tira el negocio.

Lo que tiene que estar a nombre de tu empresa, con tu email corporativo como propietario, desde el primer día:

• El dominio. Registrado a nombre de tu sociedad, con tu email de contacto. No del socio, no del informático que se fue, no de la agencia.
• El hosting o la cuenta de nube. Contrato a tu nombre, tarjeta tuya si es posible. Que la agencia tenga acceso de administrador es normal; que sea la titular, no.
• Google Ads, Meta Business, Google Analytics, Search Console, Tag Manager. Propiedad tuya, agencia con acceso de administrador. Este punto tiene matices que dan para un artículo entero, y lo tienen: de quién son tus cuentas de anuncios y tus datos.
• El repositorio de código. Que exista, y que tengas acceso de lectura al menos. Si el código solo vive en el portátil de una persona, no tienes proyecto, tienes una dependencia.
• Las cuentas de las pasarelas, los transportistas y las APIs. Redsys, Stripe, la cuenta de SEUR o de Correos Express, el token de la API del ERP. Todo a tu nombre.

Y algo que casi nunca se pide: un inventario de accesos actualizado. Un documento con todos los servicios que toca el proyecto, quién es el titular, quién tiene acceso y con qué nivel. Que se entregue al cierre y se actualice cada vez que cambie algo. Cuesta media hora al trimestre y es lo que te salva el día que se va la persona que lo sabía todo.

Garantía y mantenimiento no son lo mismo

Casi todos los presupuestos dicen «incluye 3 meses de soporte». Nadie define soporte. Estas cuatro cosas son distintas y tienen que estar separadas y con precio:

En soporte, exige tres cosas concretas: canal único (no WhatsApp del comercial), horario y tiempo de respuesta comprometido, distinguiendo entre «la tienda no cobra» y «el banner del home está torcido». Y ojo con la palabra SLA: un tiempo de respuesta de 2 horas no es un tiempo de resolución. Que quede claro cuál te están dando.

Contrapartida: un SLA agresivo cuesta dinero. Guardia de fin de semana, disponibilidad fuera de horario y penalizaciones se pagan, y un freelance solo no puede ofrecerlas honestamente porque también se pone enfermo. Si facturas 80.000 € al mes y una caída de cuatro horas un sábado te cuesta varios miles, paga el SLA. Si vendes B2B de lunes a viernes, un compromiso de respuesta en horario laboral es suficiente y te ahorras una cuota. Esa decisión enlaza directamente con a quién le encargas el trabajo.

Qué pasa el día que os separáis

Es la cláusula que nadie quiere escribir y la única que se usa cuando la relación se ha estropeado. Precisamente por eso hay que redactarla cuando todavía os lleváis bien.

Cuatro puntos:

1. Preaviso por ambas partes. Un mes o dos. Que tú puedas irte sin penalización y que ellos no puedan dejarte tirado en 48 horas.
2. Entrega de salida definida. Código completo en el repositorio, base de datos, documentación de la arquitectura, credenciales, inventario de accesos y lista de servicios de terceros con sus cuotas. Con plazo: 10 o 15 días naturales desde la baja.
3. Traspaso asistido, con precio. Unas horas para que el equipo entrante pueda preguntar. Nadie regala esto, y está bien: pon un número de horas y una tarifa. Un traspaso a ciegas puede costar semanas de reingeniería inversa.
4. Nada de rehenes. Que la entrega no esté condicionada a nada distinto de tener las facturas al día. Si hay una factura en disputa, se discute; el dominio no se retiene.

Dinero: lo que está dentro, lo que se paga aparte y lo que sube solo

Separa siempre tus costes recurrentes de terceros del precio del proyecto. Hosting, licencias anuales de módulos, apps de la tienda, herramienta de email, CDN, certificados. En una tienda mediana esto suele moverse en el entorno de unos cientos de euros al mes, pero varía muchísimo según pila y volumen; lo importante no es la cifra, es que aparezca desglosada y que sepas quién la contrata y quién la paga. Un presupuesto que se come esos costes «de momento» te está escondiendo una cuota futura.

Pide también:

• Precio/hora para lo que no está en el alcance, y si hay tramos distintos (desarrollo, diseño, gestión de proyecto).
• Cómo se aprueba un cambio de alcance. Por escrito, con estimación previa, antes de ejecutarlo. Sin esto, las horas extra aparecen en la factura final.
• Calendario de pagos ligado a hitos verificables, no a fechas. «40 % a la entrega del entorno de pruebas funcional» es un hito. «40 % en junio» no lo es.
• Revisión de precio de la cuota. Que diga si se revisa anualmente y con qué criterio. Mejor saberlo que descubrirlo en enero.

Dependencias entre proveedores: el punto que más se olvida

Si tu proyecto toca el ERP, el sistema de la tienda física, la plataforma de email y la agencia de anuncios, ese presupuesto no vive solo. Y el día que un pedido no baja al ERP, la conversación entre las dos empresas se puede alargar semanas mientras tú miras.

Lo mínimo que se puede escribir: quién es el responsable de la integración de punta a punta, quién tiene la última palabra en un desacuerdo técnico, y qué se considera «fuera de nuestro control». Cuanto más concreto sea ese último punto, mejor para todos. Es un problema con entidad propia y lo tratamos aparte en cuando el fallo es de dos proveedores, pero en el presupuesto tiene que caber al menos un párrafo.

Cómo pedir todo esto sin parecer un paranoico

No hace falta un abogado ni un pliego de 40 páginas. Manda un email corto: «antes de firmar, ¿podéis añadir un anexo con propiedad del código y licencias, titularidad de cuentas, alcance de garantía y mantenimiento, y condiciones de salida?». Un proveedor serio te dirá que sí y probablemente ya lo tenga redactado. Otro te dirá que «eso se ve sobre la marcha» o que «nunca hemos tenido problemas». Esa respuesta también es información.

Asume dos contrapartidas. La primera: exigir esto puede subir el precio entre un poco y bastante, porque un proveedor que firma condiciones de salida y compromisos de respuesta está asumiendo riesgo, y el riesgo se cobra. Es dinero bien gastado, pero es dinero. La segunda: si el proyecto es pequeño —una landing, una campaña de tres meses, un ajuste de 2.000 €— este nivel de detalle es desproporcionado y solo va a alargar el arranque. Ahí basta con dos cosas: cuentas a tu nombre y el código donde tú puedas verlo.

El resto de la lista es para lo que va a estar funcionando dentro de tres años y de lo que depende que factures. Ahí sí, cada línea que no escribas ahora la vas a pagar después, y más cara.