Tres errores que hemos cometido llevando una consultora pequeña

La lista de cosas que hemos hecho mal nos ha servido más que cualquier caso de éxito. Llevar una empresa pequeña tiene mucho de equivocarse rápido y aprender más rápido, y en Taiko, que somos tres personas, no hay un departamento que amortigüe los errores: se notan enseguida y se arreglan entre quienes los cometieron.

Hemos elegido tres, los que más nos costaron y de los que salió algo que hoy sigue en pie. Ninguno fue dramático por separado. Juntos nos enseñaron más que los aciertos, porque un acierto solo te dice “sigue” y un error te dice con bastante exactitud qué hay que cambiar.

No lo contamos por modestia. Lo contamos porque en muchos relatos de empresa sobran las victorias y falta explicar cómo se aprende de verdad.

Decir que sí a todo

Al principio, cada proyecto que entraba era un proyecto que aceptábamos. Tenía una lógica evidente: una empresa pequeña no está para rechazar trabajo. El resultado fue otro. Acabamos dispersos y agotados, con demasiadas cosas abiertas a la vez y poca capacidad de hacer bien ninguna.

Lo que aprendimos es que decir “no” a tiempo es lo que protege la calidad de los “sí”. No se trata de ser selectivos por orgullo, sino de ser honestos con lo que tres personas pueden llevar con el nivel de detalle que exige una aplicación a medida. Un proyecto aceptado sin capacidad real para atenderlo no es un ingreso, es una deuda con alguien que confió en nosotros.

Es más fácil decir “esto ahora no podemos llevarlo bien” que explicar meses después por qué algo va tarde. Si quieres ver cómo planteamos hoy el trabajo con un cliente, lo resumimos en cómo trabajamos.

No documentar mientras hacíamos

“Ya lo escribo luego” significa, casi siempre, “no lo escribo nunca”. Lo comprobamos de la manera incómoda: cuando un cliente nos preguntaba por algo de hacía seis meses, tocaba reconstruirlo de memoria. Qué se decidió, por qué se hizo así, qué se probó antes. Y la memoria, cuando hay varios proyectos en paralelo, falla justo en los detalles que importan.

De ahí viene que hoy documentemos todo en Obsidian, de forma casi obsesiva. No porque nos guste escribir, sino porque la alternativa nos salió cara. Documentar mientras se hace cuesta unos minutos en el momento. Documentar después cuesta mucho más, y a veces ya no se puede hacer: el contexto se ha perdido.

Una documentación al día sirve, sobre todo, para responder a un cliente con datos y no con recuerdos. Y para que lo decidido no dependa de que alguien se acuerde.

Dar por hecho que lo automático avisa cuando falla

Este es el más reciente, y el que mejor muestra que automatizar no es lo mismo que desentenderse. Las facturas de nuestros proveedores llegan por correo y se dan de alta solas: el correo las aparta, una tarea programada las recoge, una IA las lee dentro de FileMaker y el sistema las registra sin que nadie teclee nada. Funcionaba tan bien que dejamos de mirarlo.

Un día descubrimos que llevaba 11 días parado. Nadie se había enterado. La causa más probable era una contraseña caducada en una tarea programada del servidor: algo pequeño, aburrido y perfectamente previsible. El fallo no estaba en la automatización, sino en haber supuesto que, si algo se rompía, nos daríamos cuenta. No nos dimos cuenta, porque un proceso parado no hace ruido: simplemente deja de pasar algo que esperabas que pasara.

Lo que cambiamos fue dejar de confiar en que el sistema avise de sus propios fallos. Ahora el proceso deja una señal de vida (cuándo se ejecutó por última vez, cuánto lleva esperando lo más antiguo de la cola, cuántas facturas quedan pendientes) y la vigila un sistema que está fuera de FileMaker, nuestro Zabbix, que avisa por Slack, un canal que tampoco depende de FileMaker. Si la cola se atasca más de unos minutos, o si dejan de llegar datos, nos enteramos ese mismo día y no once días después. Es la misma idea que defendemos en copias, monitorización y nube para una pyme: enterarte tú antes de que te lo cuente otro.

Nos dejó además una frase que repetimos a menudo: que un sistema diga “procesado” no significa que esté hecho en el siguiente. Contamos el caso completo, con los detalles técnicos, en la chuleta de nuestra charla en fmCat 2026.

Lo que une los tres errores

Mirados de cerca, los tres tienen algo en común: son errores de dar algo por supuesto. Que cabía un proyecto más, que nos acordaríamos de lo decidido, que una automatización avisaría al romperse. En una empresa grande ese tipo de desajuste se reparte; en una pequeña se nota enseguida, y quizá por eso se corrige antes.

Tampoco creemos haber terminado. Seguramente estemos cometiendo ahora otros errores que solo veremos dentro de un tiempo. La diferencia es que hemos aprendido a buscarlos: preguntarnos con regularidad qué estamos haciendo por inercia, qué dejamos para luego y qué estamos dando por supuesto.

Lo que nos llevamos

Un error bien digerido vale más que un acierto que no sabemos explicar. Decir no a tiempo, escribir las cosas cuando pasan y vigilar desde fuera lo que funciona solo son tres hábitos pequeños que salieron de equivocarnos. Si te reconoces en alguno de los tres y quieres comentarlo, puedes escribirnos a través de contacto.