La IA abarató construir software. Tenerlo sigue siendo caro.

Tengo ganas de construirme una aplicación para perder peso

Necesito perder peso. Conozco la parte aburrida: comer un poco menos, moverme más y ser honesto el tiempo suficiente para que cambien los números.

Podría pagar diez euros al mes por una aplicación que lo siga. En lugar de eso, sigo pensando en construirme una pequeña.

No porque me ahorre diez euros. No lo haría. La construiría porque disfruto haciendo cosas. Porque podría hacer una pantalla que encaje exactamente con mi manera de pensar: un lugar para el peso, un registro sencillo de comida, una vista semanal que no intente convertir el desayuno en un test de personalidad. Podría tenerla funcionando en un fin de semana.

Sobre todo, el riesgo de fracaso es casi nulo. Si se rompe, escribo mis comidas en Notas durante una semana. Si dejo de mantenerla, no se detiene nada importante. Ningún cliente espera. Nadie se queda sin cobrar. No hay revisión de seguridad, onboarding ni informe de cierre de trimestre que dependa de ella.

Esa es una buena razón para construir algo.

No es una razón suficiente para que una empresa construya su propio software operativo.

«¿No podríamos hacer simplemente un CRM pequeño?»

Un cliente me hizo esta pregunta hace poco. No quería Salesforce. No necesitaba todas las funciones de HubSpot. Necesitaba contactos, operaciones, recordatorios, algunos informes y automatización. «¿No podríamos hacer simplemente un CRM pequeño nosotros mismos?»

La respuesta sincera es: sí, probablemente. Una persona competente, con buenas herramientas, puede construir ahora una primera versión respetable con rapidez. La IA ha cambiado ese cálculo. Una pantalla que antes pedía días puede pedir horas. Un flujo que necesitaba un desarrollador puede empezar con un prompt, una base de datos y algunas integraciones.

Es un avance real. Lo uso todos los días.

Pero la pregunta no es si puede construir la versión uno. La pregunta es qué ha aceptado poseer cuando esa versión se vuelve lo bastante útil como para que otras personas dependan de ella.

Son preguntas distintas. La segunda suele ser la cara.

La IA cambió el coste de empezar, no el de tenerlo

La IA ha reducido el coste de fabricar software. No ha eliminado el trabajo que empieza cuando ese software entra en la empresa.

Una herramienta que usa solo usted puede seguir siendo un boceto útil. En cuanto cinco personas la usan para llevar una parte del negocio, se convierte en un sistema. Alguien necesita el acceso correcto. Alguien debe entender qué pasa cuando una automatización falla. Alguien debe explicar por qué cambió un número. Alguien debe decidir qué hace la herramienta cuando el mundo real se niega a encajar en el caso ideal.

Después llegan las peticiones. ¿Podemos añadir este campo? ¿Puede funcionar también para España? ¿Por qué se duplicó este registro? ¿Puede finanzas ver esto sin editarlo? ¿Por qué el cliente no recibió el email? ¿Puede conectarse a la nueva herramienta de presupuestos? ¿Puede formarse la nueva persona de ventas antes del lunes?

Ninguna de esas preguntas demuestra que la herramienta se construyó mal. Es lo que ocurre cuando una herramienta útil se encuentra con una empresa real.

Los proveedores de software emplean product managers, equipos de soporte, especialistas de seguridad, equipos de implantación e ingenieros porque estas preguntas no dejan de llegar. No evita ese trabajo al poseer la herramienta. Simplemente lo trae dentro.

La factura rara vez es el coste mayor

El software interno tiene costes visibles: mantenimiento, errores, seguridad, permisos, documentación, integraciones, migraciones, onboarding, evolución de producto, soporte y continuidad cuando se va quien lo construyó.

La mayoría de los equipos los conoce en teoría. Aun así los subestiman porque la primera versión parece tan limpia. Quien la creó conoce los atajos. Los datos todavía son simples. Nadie ha pedido una excepción.

Luego una persona de ventas cambia de territorio. Un cliente tiene dos entidades legales. Alguien necesita un informe que compare este trimestre con el anterior. Llega una nueva fuente de datos. Entra una solicitud de privacidad. Quien creó la herramienta está de vacaciones, ocupado o ya no está.

La factura no siempre es dramática. Llega en fragmentos: diez minutos aquí, un viernes por la tarde allí, una reunión que debía ser sobre clientes y se convierte en una conversación sobre permisos. Por eso es fácil no verla.

El mayor coste no suele ser el desarrollo. Es la atención de la dirección y del equipo.

Cuando el sistema comercial se convierte en el proyecto

Esto importa especialmente en los equipos comerciales porque las herramientas de ventas son muy buenas creando sensación de avance.

Una empresa puede pasar semanas mejorando la estructura del CRM, las automatizaciones, los dashboards, el scoring de leads, la limpieza de datos y los flujos internos. Cada tarea es concreta. Cada una produce algo visible. Un pipeline más limpio da la misma satisfacción que una mesa recién ordenada.

Mientras tanto, el trabajo difícil sigue donde estaba. No se llama a los clientes. No se revisan las operaciones estancadas. La cualificación sigue siendo vaga. Los managers no hacen coaching. Las reuniones de forecast hablan del número en lugar de la operación. Nadie aprende por qué las oportunidades no avanzan.

El dashboard puede volverse más exacto sobre un proceso que sigue siendo débil.

He visto equipos culpar al CRM de problemas que en realidad eran decisiones comerciales que nadie había tomado. Las etapas no estaban claras porque nadie había acordado qué significaba una oportunidad cualificada. El forecast era erróneo porque los comerciales no tenían motivo para decir que una operación se estaba retrasando. El seguimiento era irregular porque nadie era dueño del siguiente paso, no porque faltara un campo.

A veces el CRM sí es malo. Sustituirlo o personalizarlo es entonces exactamente la decisión correcta. Una herramienta puede facilitar el buen trabajo y hacer más difícil ocultar el malo.

Pero las herramientas deben resolver un problema comercial claramente identificado. No deben convertirse en el proyecto porque rehacerlas parece más abordable que afrontar el problema.

El mayor coste de construir sus propias herramientas comerciales suele ser lo que el equipo deja de hacer mientras las construye.

Construya para una ventaja concreta, no porque el estándar le moleste

Hay buenas razones para construir software interno. Su proceso puede ser verdaderamente singular. La herramienta puede estar en el centro de un servicio propietario. Puede permitirle entregar algo que los competidores no saben copiar. Un producto maduro puede resolver solo la mitad de la necesidad y obligar a que la otra mitad siga siendo manual todos los días.

En esos casos, construir puede ser la decisión más barata precisamente porque elimina una restricción operativa real.

Pero la irritación no es una diferencia estratégica. Todo producto SaaS maduro tiene partes torpes, sobredimensionadas o diseñadas para otra persona. Es el precio de comprar un producto que ha sobrevivido a miles de empresas con hábitos distintos.

Si un producto resuelve el ochenta por ciento de la necesidad, el veinte por ciento restante puede ser un problema de formación, de configuración o un proceso que conviene simplificar. También puede ser la parte que más importa. La cuestión es saber cuál es antes de empezar a construir.

Cinco preguntas antes de abrir el editor

No necesita una matriz para esto. Haga cinco preguntas sencillas.

¿Es estratégicamente diferenciador? ¿Tener esta capacidad cambiará lo que los clientes nos compran o estamos rehaciendo una función estándar porque la herramienta actual nos irrita?

¿Qué ocurre si falla? Si se equivoca durante un día, ¿el equipo puede sortearlo? ¿O interrumpe ventas, facturación, accesos, cumplimiento o servicio al cliente?

¿Ya existe un producto maduro que resuelva el ochenta por ciento? No un producto que haga una buena demo. Uno que su gente pueda usar de verdad, con soporte e integraciones ya disponibles.

¿Quién lo posee dentro de seis meses? Nombre a la persona, el presupuesto y el tiempo. «Quien lo construyó» no es un modelo de propiedad.

¿Qué trabajo importante no hacemos mientras lo construimos? Sea específico. ¿A qué clientes no se llamará? ¿Qué operaciones no se revisarán? ¿A qué managers no se hará coaching? ¿Qué decisión esperará?

La última pregunta es la que haría primero. Construir puede dar la sensación de moverse mientras aleja silenciosamente a la empresa del trabajo que genera ingresos.

Devuelva la herramienta a su sitio

Probablemente construiré la aplicación para perder peso. Es una apuesta pequeña, cercana y divertida. Si se convierte en un desastre, puedo borrarla sin llamar a nadie.

Un CRM de empresa no es eso. Tampoco lo es el flujo de presupuestos, la base de datos de clientes, el stack financiero o la herramienta que decide a quién seguir después.

La IA facilita construirlos todos. No hace desaparecer el coste de poseerlos. Que sea divertido de construir no significa que sea inteligente poseerlo para siempre.

Si su equipo dejara de mejorar sus herramientas internas durante un mes, ¿qué problema de cliente tendría por fin tiempo de resolver?