Cuándo compensa un módulo a medida para tu tienda y cuándo no

Este artículo va de cuándo merece la pena programar una pieza para tu tienda y cuándo no. Si ya sabes que la necesitas, lo hacemos en módulos y conectores a medida.

El reflejo, cuando a una tienda le falta algo, es buscar un módulo en el marketplace. Y está bien: la mayoría de las veces existe, cuesta poco y se instala en una tarde.

El problema aparece cuando lo que existe se parece a lo que necesitas, pero no es lo que necesitas. Ahí empieza una decisión que casi nadie toma con criterio.

Primero: busca, de verdad

Antes de valorar nada, dedica un rato a buscar. Y al mirar cada candidato, fíjate en tres cosas más allá del precio:

• Cuándo se actualizó por última vez. Si hace más de un año, da igual lo bien que esté: es una deuda con fecha.
• Con qué versiones dice ser compatible. Y si menciona la tuya explícitamente o «hasta la anterior».
• Qué dicen las valoraciones malas. Las buenas no informan; las de dos estrellas cuentan exactamente dónde falla.

Si encuentras uno mantenido que hace lo que necesitas, cómpralo y no le des más vueltas. Programar lo que ya existe es de las peores inversiones que se pueden hacer.

Los cuatro casos en los que compensa lo tuyo

1. Lo que necesitas es de tu negocio, no de tu sector

Una regla de precios que depende de a qué distancia está el cliente y de si tiene contrato anual. Un cálculo de plazo de entrega que mira tu stock, el de tu proveedor y el calendario de tu transportista. Eso no lo va a vender nadie, porque solo lo necesitas tú.

2. Hay que hablar con otro sistema tuyo

El caso más frecuente y el que más tiempo ahorra. La tienda tiene que leer stock y precios del ERP y devolverle los pedidos. Existen conectores genéricos, pero encajan si tu ERP es uno de los cuatro habituales y lo usas de forma estándar. En cuanto tengáis un campo propio o una regla vuestra, el genérico se queda a medias.

3. Lo que hay trae diez veces más de lo que quieres

Instalar un módulo de cuatro megas con veinte funciones para usar una sola no es gratis: pesa en cada carga de página, hay que actualizarlo igual y amplía la superficie de ataque. Si lo tuyo son doscientas líneas, doscientas líneas.

4. La pieza sostiene algo crítico

Si de ese módulo dependen los cobros, las reservas o los datos de tus clientes, la pregunta no es cuánto cuesta: es qué pasa el día que el autor lo abandone. A veces la respuesta razonable es tenerlo tú.

Cuándo NO compensa

Vale la pena ser igual de claro por el otro lado:

• Cuando existe y está mantenido. Ya está.
• Cuando lo que quieres es un cambio visual. Eso es el tema de la tienda, no un módulo. Meterlo en un módulo lo convierte en algo que se rompe en cada actualización.
• Cuando el ahorro es de minutos al mes. Programar tiene un coste fijo que no baja de cierto suelo, y hay automatizaciones que nunca lo amortizan.
• Cuando el proceso todavía cambia cada mes. Programar una forma de trabajar la fija. Si aún estáis probando, esperad.

La cuenta, sin misterio

Se hace en cinco minutos y evita discusiones:

1. Cuánto tiempo se va hoy en hacer eso a mano, al mes.
2. Por lo que cuesta esa hora en tu empresa.
3. Contra el coste de desarrollarlo más lo que va a costar mantenerlo cada año.

Ese tercer punto es el que se olvida siempre. Un módulo propio hay que revisarlo cuando salga la versión mayor siguiente de tu tienda, y eso es tiempo que hay que presupuestar desde el principio, no descubrir dos años después.

Y hay un factor que no aparece en la cuenta y decide más de lo que parece: los errores. Un dato que se copia a mano se teclea mal de vez en cuando. Cuando ese dato es un precio o un stock, el coste no es el minuto: es el pedido servido mal.

Si decides desarrollarlo, tres condiciones

• Que use los puntos de extensión de la plataforma y no toque el núcleo. Si hay que modificar archivos del sistema, la primera actualización se lo lleva por delante.
• Que esté aislado. Un módulo que hace una cosa se entiende, se prueba y se sustituye. Uno que hace siete es imposible de tocar sin miedo.
• Que se pueda desactivar. Si al apagarlo la tienda deja de vender, no era un módulo: era un parche sobre el que se apoya todo.

Y una condición previa a las tres: que el código sea tuyo y esté en un sitio al que tengas acceso. Suena obvio y es la sorpresa más frecuente cuando hay que cambiar de proveedor.

Qué pedir en el presupuesto

Un módulo se presupuesta mal cuando se describe por lo que hace y no por lo que ocurre en los casos raros. Pide que aparezcan:

• Qué pasa cuando falla. Si el módulo habla con otro sistema y ese sistema no contesta, ¿reintenta, avisa, se queda callado?
• Con qué versiones es compatible y qué costaría adaptarlo a la siguiente versión mayor de la plataforma.
• Si trae pantalla de configuración o hay que llamar al proveedor cada vez que cambie un valor.
• Dónde queda el código, y que sea un sitio al que tengas acceso desde el primer día.

Ese último punto decide más de lo que parece: es la diferencia entre poder cambiar de proveedor y tener que rehacerlo todo. Lo desarrollamos en qué preguntar a un proveedor.

Por dónde empezar

Escribe en dos líneas qué tiene que pasar, con un ejemplo real de esta semana. No «gestionar mejor el stock», sino «cuando entra un pedido de más de diez unidades, el sistema tiene que avisar a producción y bloquear esa cantidad durante 48 horas».

Con esas dos líneas se puede buscar si existe, y si no existe, se puede presupuestar. Sin ellas, ni una cosa ni la otra.

Si quieres una opinión, cuéntanos qué te falta. Cuando lo resuelve un módulo del mercado, te decimos cuál.