Interfaces API: contrato, propiedad y salida

01 — Contrato

Qué debe aclararse por escrito

• Propiedad de datos y accesos. Pertenecen al cliente. Si un proveedor no lo confirma claramente, esa es la información más importante de la conversación.
• Entrega en caso de finalización. En qué formato, en qué plazo, a qué costes.
• Sin permanencia mínima sin contraprestación. La vinculación es defendible si se entrega algo a cambio — si no, no.
• Qué cuesta un cambio posterior. No es el precio del proyecto lo que decide sobre los costes totales, sino la tarifa horaria para el tercer año.
• Documentación como objeto de entrega. No como promesa, sino como partida en el presupuesto.

02 — Preguntas

Preguntas que deberías hacer

• ¿Qué pasa si el proyecto se vuelve más caro de lo estimado — quién lo asume?
• ¿A quién pertenecen los datos, los accesos y, si se desarrolla, el código fuente?
• ¿Qué cuesta la operación en el segundo y tercer año?
• ¿Cómo es la documentación que recibimos al final?
• ¿Con qué medirían si el proyecto fue exitoso?
• ¿Hay algún caso en el que nos desaconsejarían esto?

03 — Señales de alerta

Cuándo deberías ser escéptico

• Resultados garantizados. Quien promete el primer lugar en Google o un aumento de facturación específico está vendiendo algo que no puede entregar.
• Ningún no. Un proveedor que considera buena idea cada proyecto o no ha escuchado o solo vende.
• Presión de tiempo. Descuentos limitados en precios de proyecto son una herramienta de ventas, no una oferta.
• Relaciones de propiedad poco claras. Quien no dice claramente a quién pertenecen datos y accesos no tiene buenas intenciones.
• Ninguna persona de contacto con conocimientos técnicos. Si en la primera conversación solo hay ventas, los malentendidos surgen ahí.