Software a medida para empresas en Baleares: qué debe ser tuyo cuando termina el proyecto

Cuando una empresa encarga software a medida en Baleares, casi toda la conversación gira en torno a lo que hará el programa: qué pantallas tendrá, qué procesos resolverá, cuánto tardará. Mucho menos se habla de una pregunta que aparece justo al final, el día de la entrega: ¿qué es tuyo exactamente?

Parece un detalle legal, pero es operativo. Si mañana quieres cambiar de proveedor, contratar a un programador interno o simplemente saber dónde están tus datos, la respuesta depende de lo que se haya dejado a tu nombre. En este artículo repasamos, pieza por pieza, qué debería quedar bajo tu control cuando termina un proyecto de software a medida para empresas en Mallorca, Ibiza, Menorca o Formentera, y cómo comprobarlo sin ser técnico.

Por qué esto importa más de lo que parece

Un software a medida no es solo un conjunto de pantallas. Detrás hay varias capas que viven en sitios distintos:

• El código fuente, que suele estar en un repositorio (GitLab, GitHub o similar).
• El servidor o la nube donde se ejecuta.
• La base de datos con la información de tu negocio.
• El dominio y los certificados que hacen que funcione en internet.
• Las cuentas de servicios externos: envío de correos, pasarela de pago, mapas, mensajería, inteligencia artificial.
• La documentación que explica cómo está montado todo.

Si cualquiera de estas piezas está a nombre del proveedor y no tuyo, dependes de él aunque el contrato diga que el software es de tu propiedad. No hace falta mala fe para que esto sea un problema: basta con que el proveedor cierre, cambie de prioridades o simplemente tarde en responder en plena temporada alta.

Un ejemplo hipotético para aterrizarlo

Imagina una empresa de mantenimiento de piscinas con equipos en Mallorca e Ibiza. Encarga una aplicación interna para asignar rutas, registrar cada visita con fotos y enviar al cliente un parte por correo. El proyecto sale bien y el equipo lo usa a diario.

Dos años después quieren añadir facturación y descubren que:

• El repositorio está en la cuenta personal del programador.
• El servidor se paga con la tarjeta del proveedor y la empresa no tiene acceso.
• El servicio de envío de correos está registrado con el email del proveedor.
• No existe ningún documento que explique cómo desplegar una nueva versión.

Nada de esto impide que la aplicación funcione hoy. Pero cualquier cambio, o cualquier problema, pasa obligatoriamente por una sola persona. Es un escenario evitable si se revisa al cerrar el proyecto.

La lista: qué debe estar a tu nombre

1. Repositorio de código

El código debe estar en una cuenta u organización de tu empresa, con el proveedor como colaborador invitado, no al revés. Así, si la relación termina, solo tienes que retirar el acceso.

Comprueba que puedes entrar con tu propio usuario y que ves el historial de cambios, no solo una copia comprimida del código.

2. Servidor y nube

La cuenta del proveedor de hosting o nube debe estar a nombre de la empresa y con su forma de pago. El proveedor de desarrollo puede tener acceso técnico, pero tú debes poder entrar, ver las facturas y, si hace falta, dar acceso a otra persona.

3. Base de datos y copias de seguridad

Pregunta tres cosas concretas:

• ¿Dónde se guardan las copias de seguridad?
• ¿Cada cuánto se hacen?
• ¿Se ha probado alguna vez a restaurar una?

Una copia que nunca se ha restaurado es una suposición, no una garantía. Pide también que sepas exportar tus datos en un formato estándar (por ejemplo, hojas de cálculo o CSV) sin depender del programador.

4. Dominio y DNS

El dominio debe estar registrado a nombre de la empresa, con un email que controles. Es una de las piezas más fáciles de perder y de las más difíciles de recuperar.

5. Servicios externos e integraciones

Haz una lista de todos los servicios de terceros que usa el software: pagos, correo, SMS, WhatsApp, mapas, IA, analítica. Para cada uno, anota a nombre de quién está la cuenta y quién recibe la factura. Lo ideal es que todos estén a nombre de la empresa, sobre todo los que manejan dinero o datos de clientes.

6. Documentación mínima

No hace falta un manual de cien páginas. Basta con un documento claro que explique:

• Qué piezas forman el sistema y dónde está cada una.
• Cómo se instala en un entorno nuevo.
• Cómo se publica una nueva versión.
• Qué variables o claves necesita para funcionar (sin escribir las claves en el documento).
• A quién avisar si algo falla.

La prueba de fuego: ¿podría otro programador entender el sistema leyendo ese documento y el código, sin llamar a nadie?

Cómo comprobarlo sin ser técnico

Puedes hacer una revisión sencilla en una tarde con este orden:

1. Pide la lista de accesos: una tabla con cada servicio, su URL, a nombre de quién está y quién tiene acceso.
2. Entra tú mismo en cada uno con tu usuario. Si no puedes, ese punto no está cerrado.
3. Revisa las facturas: si un servicio lo paga el proveedor, pregunta por qué y cuándo se transfiere.
4. Pide una restauración de prueba de la base de datos en un entorno separado.
5. Comprueba la licencia: el contrato debe dejar claro qué derechos tienes sobre el código desarrollado para ti y qué partes son librerías o componentes de terceros con su propia licencia.

Lo que razonablemente puede no ser tuyo

Ser propietario no significa que todo deba ser exclusivo. Es normal que un proveedor use:

• Librerías de código abierto, que tienen sus propias licencias.
• Componentes propios que reutiliza entre proyectos, siempre que tengas licencia de uso indefinida para tu caso.
• Herramientas internas de trabajo que no forman parte del producto final.

Lo importante es que esté por escrito y que nada de eso te impida mantener o mover el software en el futuro.

Mantenimiento: la otra mitad de la propiedad

Tener el código a tu nombre no sirve de mucho si nadie lo mantiene. Antes de cerrar el proyecto, acuerda:

• Quién aplica las actualizaciones de seguridad y con qué frecuencia.
• Cómo se reportan y priorizan los fallos.
• Qué tiempo de respuesta necesitas en temporada alta, cuando en Baleares muchos negocios no pueden permitirse que el sistema se pare.
• Qué pasa si decides terminar el mantenimiento: cuánto preaviso y qué se entrega.

Criterios para decidir con qué proveedor trabajar

Si estás valorando propuestas de software a medida para empresas en Baleares, estas preguntas te ayudan a separar opciones:

• ¿Propone crear las cuentas a nombre de tu empresa desde el primer día?
• ¿Incluye documentación como entregable, no como extra opcional?
• ¿Explica con claridad qué componentes son de terceros?
• ¿Tiene un procedimiento de salida definido por si la relación termina?

Un proveedor que responde a todo esto sin rodeos suele ser también uno con el que el día a día es más sencillo.

Cómo lo hacemos en Derek Solutions

En nuestros proyectos de desarrollo de software a medida en Palma de Mallorca trabajamos para que el repositorio, el servidor, el dominio y los servicios externos queden a nombre de cada empresa, y entregamos la documentación necesaria para que el sistema no dependa de una sola persona. Damos servicio a negocios de Mallorca, Ibiza, Menorca y Formentera.

Si estás pensando en un software para tu empresa o quieres revisar si el que ya tienes está bien atado, escríbenos a derek@dereksolutions.com, llámanos al +34 680 283 973 o usa nuestro formulario de contacto. Lo revisamos contigo sin compromiso.