Aplicación de negocio: ¿a medida o herramienta del mercado?

¿Hay que encargar el desarrollo de una aplicación de negocio o suscribirse a un software del mercado? La pregunta suele llegar tras meses de hojas de cálculo compartidas y mensajes que se pierden, cuando el equipo tiene la impresión de trabajar para la herramienta y no al revés. No hay una respuesta correcta universal, pero hay señales que inclinan hacia un lado, y una tercera vía que a menudo se olvida: conservar la herramienta del mercado y añadirle lo que le falta.

En resumen

• La herramienta del mercado gana mientras su forma de trabajar quepa en sus casillas: cuesta menos y arranca enseguida.
• El desarrollo a medida se justifica cuando sus equipos esquivan la herramienta cada día, o cuando su forma de trabajar es su ventaja.
• Compare a tres años, contando el tiempo perdido en rodeos, no solo la suscripción frente al presupuesto.
• Antes de sustituir un software, compruebe si no basta con una pequeña aplicación que se conecte a él.

Lo que compra realmente en cada caso

Las dos opciones no compran lo mismo, y es ahí donde la comparación se falsea con más frecuencia.

El coste de explotación de una aplicación a medida no es nulo, pero suele ser modesto al principio. A modo de ejemplo, el plan Pro de Supabase, un back-end extendido para este tipo de aplicación, empieza en 25 USD al mes con copias de seguridad diarias, según su página de precios. El detalle de estas partidas está en nuestro artículo sobre lo que hace variar el precio de una aplicación.

Las señales que inclinan hacia la herramienta del mercado

Un software del mercado suele ser la buena elección, y no hay ninguna vergüenza en decirlo. Se impone cuando:

• El proceso es estándar. Contabilidad, nóminas, facturación: los editores han puesto en ello años de reglas y casos particulares, y los actualizan cuando cambia la ley.
• El equipo está dispuesto a adoptar el método de la herramienta. Si la forma de trabajar del software vale tanto como la suya, adoptarla es más barato que reconstruirla.
• Tiene que empezar la semana que viene. Una suscripción se abre en un día; una aplicación, incluso rápida, exige un encuadre.
• Nadie se hará cargo de la herramienta internamente. Una aplicación a medida necesita un responsable que decida sus evoluciones.

Las señales que inclinan hacia el desarrollo a medida

A la inversa, algunas señales no engañan:

• Sus equipos esquivan la herramienta cada día. Una hoja de cálculo al lado del software, fotos enviadas por mensajería, información introducida de nuevo por la noche: cada rodeo es un coste que la suscripción no muestra.
• Su forma de trabajar es su ventaja. Si un cliente le elige por la forma en que sigue su expediente, plegarla a una herramienta genérica es debilitarla.
• Algunas reglas deben ser exactas, sin excepción. Un contador, una fecha, un derecho de acceso: cuando un error cuesta caro, la regla debe aplicarla el servidor, no la buena voluntad de cada uno.
• El precio por usuario sube más rápido que el uso. Cuando el equipo crece, la suscripción le sigue, incluso para personas que consultan dos pantallas a la semana. El cálculo completo está en nuestro artículo sobre el coste de un software por suscripción a tres años.

La vía intermedia: ampliar la herramienta en lugar de sustituirla

Entre «comprarlo todo» y «construirlo todo», existe una opción a menudo más barata: conservar el software que hace bien lo esencial y añadirle una pequeña aplicación para la función que falta.

Palmora Property, una plataforma de intermediación inmobiliaria en Phuket a la que acompañamos, gestiona sus anuncios desde el CRM Twenty, autoalojado, que le sirve de back-office. Al equipo le faltaba una función: ordenar las fotos de un anuncio y cambiar su estado sin salir del CRM. En lugar de sustituir la herramienta, le añadimos una pequeña aplicación a medida, descrita en el caso de estudio Palmora. El CRM sigue haciendo lo que hace bien, la aplicación solo hace lo que faltaba.

Esta vía supone un software abierto: una interfaz de programación documentada, la posibilidad de añadirle objetos o aplicaciones. Es un criterio que hay que comprobar antes de elegir una herramienta, y es lo que detallamos en nuestro artículo sobre Twenty utilizado más allá del CRM. A veces basta una simple automatización entre dos programas, sin ninguna pantalla: véase cuando basta una regla, sin IA.

Cómo comparar ambas a tres años

1. 01Escribir lo que la herramienta debe hacer el primer día.

   No la lista soñada: lo que sirve en el lanzamiento y lo que esperará.

2. 02Calcular la suscripción a tres años.

   Con el número de usuarios previsto al final, no el de hoy, y las opciones de pago que necesitará.

3. 03Calcular el desarrollo a medida a tres años.

   El desarrollo, la explotación mensual y el mantenimiento: el presupuesto de una aplicación tras su puesta en línea se prevé desde el presupuesto.

4. 04Medir los rodeos.

   Las horas que se pasan cada semana volviendo a introducir datos, buscando, insistiendo: es el coste oculto de la herramienta mal ajustada.

5. 05Comprobar la puerta de salida.

   En ambos casos, ¿puede recuperar sus datos en un formato legible si cambia de opinión?

Lo que el desarrollo a medida no resuelve

Una aplicación no aclara un proceso confuso: lo congela. Si nadie sabe decir quién valida qué, la aplicación codificará la duda. Es mejor escribir primero el recorrido y luego probarlo con las personas que lo usarán, por ejemplo con un prototipo navegable, antes de la primera línea de código.

Tampoco sustituye la adopción. Una aplicación que el equipo no ha pedido acaba al lado de la hoja de cálculo que debía sustituir. Las personas que la usarán deben estar en el circuito desde el encuadre.

Si gana el desarrollo a medida, nuestro desarrollo de aplicaciones empieza con un encuadre escrito de lo que la aplicación hace el primer día, y luego pone una versión en manos de sus primeros usuarios antes de pensar en las tiendas.

Preguntas frecuentes

Fuentes

1. Página de precios de Supabase (nueva pestaña)supabase.com