Hacer un programa para mi empresa en Palma de Mallorca: qué pasa desde la primera llamada hasta que tu equipo lo usa

Mucha gente no busca «software a medida». Escribe lo que tiene en la cabeza: «hacer un programa para mi empresa», y le añade «Palma de Mallorca» porque quiere a alguien cerca. Detrás de esa frase casi siempre hay lo mismo: una hoja de Excel que ya no aguanta, partes en papel que se pierden, un grupo de WhatsApp que hace de sistema de gestión y la sensación de que el negocio ha crecido más rápido que sus herramientas.

Lo que casi nadie explica es qué pasa después de esa búsqueda. ¿Qué te van a pedir? ¿Cuándo ves algo funcionando? ¿Qué decisiones te tocan a ti y cuáles no deberías tener que tomar? Este artículo recorre el camino completo, fase a fase, con un ejemplo hipotético para que se entienda en concreto.

El ejemplo que usaremos

Imagina una empresa de mantenimiento de piscinas con base en Palma y clientes por toda Mallorca. Tiene unos pocos técnicos en la calle, una persona en oficina y al dueño, que hace un poco de todo. Hoy funciona así:

• Los avisos entran por teléfono y WhatsApp, y se apuntan en una libreta o en el móvil de quien los coge.
• Cada técnico rellena un parte en papel con lo que ha hecho y los productos que ha usado.
• A fin de mes, la oficina pasa los partes a Excel para facturar. Siempre falta alguno.

El dueño quiere «un programa». Veamos qué significa eso en la práctica.

Fase 1: la primera conversación (y lo que no debería pasar en ella)

Qué haces tú: contar cómo trabajas hoy, sin maquillarlo. Lo más útil que puedes llevar es un día normal contado de principio a fin: quién recibe el aviso, dónde se apunta, quién lo asigna, cómo se cierra y cómo se cobra.

Qué hacemos nosotros: preguntar mucho y proponer poco. En esta fase todavía no tiene sentido hablar de tecnologías ni de pantallas.

Señal de alarma: si en la primera llamada alguien te da un precio cerrado sin haber entendido tu proceso, está presupuestando un programa genérico, no el tuyo.

Fase 2: el mapa del proceso y el «problema que más duele»

Antes de escribir una línea de código hay que dibujar el proceso actual y marcar dónde se pierde tiempo o dinero. En el ejemplo de las piscinas, el mapa revelaría probablemente tres puntos críticos:

1. Avisos que se pierden porque nadie los registra en un sitio común.
2. Partes que llegan tarde o incompletos, y por tanto facturas que salen tarde.
3. Productos usados que no se cobran porque nadie los apunta.

Qué decides tú: cuál de esos problemas es el que más te cuesta. El primer programa no tiene que resolverlo todo; tiene que resolver bien uno. Aquí suele estar la diferencia entre un proyecto que se usa y uno que se abandona.

Qué te llevas: un documento corto con el proceso actual, el proceso propuesto y lo que entra (y lo que no) en la primera versión. Ese documento es tuyo aunque decidas no seguir.

Fase 3: ver el programa antes de que exista

Con el alcance claro, se preparan pantallas de prueba: maquetas navegables que puedes tocar en el móvil o en el ordenador. No funcionan de verdad, pero sirven para responder preguntas muy concretas:

• ¿El técnico puede cerrar un parte con una mano, en la calle, con el sol de agosto en la pantalla?
• ¿La oficina ve de un vistazo qué avisos están sin asignar?
• ¿Los campos del parte son los que realmente necesitas para facturar?

Qué haces tú: enseñárselas a quien va a usarlas cada día, no solo revisarlas tú. Un técnico detecta en dos minutos un botón que sobra o un dato que falta.

Fase 4: construir por entregas cortas

Aquí empieza el desarrollo de verdad. La forma sensata de hacerlo es por entregas pequeñas que puedes probar, no un gran estreno al final. En el ejemplo, el orden podría ser:

1. Registro de avisos y asignación a técnicos.
2. Parte digital desde el móvil, con fotos y productos usados.
3. Exportación de lo realizado para facturar (o conexión con el programa de facturación que ya usas).

Qué haces tú: probar cada entrega con casos reales y decir lo que no encaja. Cuanto antes llegue esa respuesta, más barato es cambiar.

Qué hacemos nosotros: enseñarte cada entrega funcionando, no un informe de avance. Si lo único que recibes son porcentajes, pregunta qué puedes probar hoy.

Fase 5: la puesta en marcha (la fase que más se subestima)

Un programa nuevo no empieza a ahorrar tiempo el primer día. Antes hay que:

• Pasar los datos que importan: clientes, direcciones, equipos instalados. No hace falta migrar diez años de historia; a menudo basta con lo activo.
• Elegir el momento: en una empresa de piscinas en Mallorca, cambiar de sistema en pleno julio es una mala idea. Lo razonable es arrancar en temporada baja y llegar a la temporada fuerte con el equipo ya acostumbrado.
• Convivir unos días con el sistema anterior: por si algo falla, que nadie se quede sin saber a qué casa ir.
• Formar en corto: una sesión práctica por perfil (técnicos, oficina, dirección) vale más que un manual largo.

Fase 6: después del lanzamiento

Las primeras semanas de uso real sacan ajustes que nadie vio en las pruebas. Es normal y conviene tenerlo previsto. A partir de ahí, el programa puede crecer por pasos: un portal para que el cliente vea sus visitas, avisos automáticos de mantenimiento o, más adelante, automatización con IA para clasificar los avisos que llegan por WhatsApp.

Qué deberías tener por escrito: quién es el dueño del código y de los datos, cómo se hacen las copias de seguridad, qué cubre el mantenimiento y qué se paga aparte.

Tres decisiones que solo puedes tomar tú

Un buen equipo técnico te ahorra muchas decisiones, pero estas son tuyas:

1. Qué problema va primero. Nadie conoce mejor que tú dónde pierde dinero tu negocio.
2. Quién va a usarlo de verdad. Si el programa no lo adoptan los técnicos o la oficina, da igual lo bien hecho que esté.
3. Qué no entra. Decir «esto, más adelante» es lo que hace que la primera versión llegue a tiempo.

Las decisiones técnicas (lenguaje, base de datos, servidor) deberían explicártelas en palabras sencillas, pero no deberías tener que tomarlas a ciegas.

Cómo saber si el proyecto va bien

Va bien si:

• Ves algo funcionando cada poco tiempo y puedes probarlo.
• Las conversaciones giran en torno a tu proceso, no a la tecnología.
• Te dicen que no a cosas que no aportan, aunque las pidas tú.

Se está torciendo si:

• Pasan semanas sin nada que tocar.
• El alcance crece en cada reunión y nadie lo apunta.
• No tienes claro quién será el dueño del código cuando termine.

¿Y si tu empresa está en Ibiza o en Menorca?

El proceso es el mismo. Gran parte del trabajo se puede hacer en remoto con videollamadas y entregas que pruebas desde tu oficina, y las sesiones clave (el mapa del proceso y la puesta en marcha) se pueden planificar presencialmente. Lo importante en cualquier isla de Baleares es lo mismo: alguien que entienda la temporada, los picos de trabajo y cómo se trabaja aquí.

¿Hablamos de tu programa?

Si estás pensando en hacer un programa para tu empresa en Palma de Mallorca o en cualquier punto de Baleares, el primer paso no cuesta nada: cuéntanos cómo es un día normal en tu negocio y te diremos qué problema atacaríamos primero y si de verdad necesitas algo a medida. Puedes ver cómo trabajamos en nuestra página de desarrollo de software a medida en Palma de Mallorca o escribirnos directamente a derek@dereksolutions.com o llamarnos al +34 680 283 973.