Una solución a un problema que no lo tenía

Hace unos meses escribí un artículo llamado "de problema familiar a producto real", donde explicaba desde la importancia de entender el problema antes de escribir el código, hasta por qué la versión simplista en cuanto a diseño era un acierto para un ERP de gestión de talleres.

Este es uno de los tantos ejemplos donde destiné tiempo a investigación, análisis, desarrollo, puesta a producción, iteración, pruebas QA, solicitud de feedback, etc. Sin embargo, este a nivel solución, tenía un plus que los otros no.

Tallercito venía a solucionar un problema de mi familia, donde la gestión de los talleres es literalmente, un caos, teniendo WhatsApp como nucleo central, audios esparcidos por todos lados, capturas de pantallas, pdfs de transferencias, charlas con proveedores por repuestos por un lado, con los clientes por el otro, donde en el 99% de los casos, también convive la vida personal, con el WhatsApp laboral.

Y si bien, un bot de WhatsApp quizás hubiese sido la mejor solución, todos en IT saben qué tan desgastante puede ser tener los permisos suficientes para si quiera pensar en esto de forma seria, al menos, en free-tier mode.

Teniendo esto en mente, opté por utilizar Next + TursoDB + Tailwinds, con Stitch Design como nexo entre la idea, al diseño que quería plasmar. Y si bien el repositorio cuenta con algunas virtudes de control de calidad, como testing unitarios, de integración, dependabot, husky, y un largo etc.

Todo eso, no sirve de nada, si el producto NO TIENE USUARIOS.

Si un producto es extensible, escalable, e incluso con una calidad envidiable, no sirve hasta que tiene usuarios reales, que lo utilizan en el día a día, porque es para ellos quienes al final resolvemos problemas. Todo lo demás, muchas veces es para seguir nuestros criterios propios de aceptación, que si bien, no está mal, a veces es tiempo y esfuerzo innecesario. Y aquí fue donde estuvo mi error.

Tuve feedback de usuarios reales, de hecho agunos excelentes donde me marcaron errores del flujo e incluso me solicitaron features. Entonces, ¿qué falló?

La cultura como centro del desastre

Haciendo un recap, tenía un producto desarrollado con estándares que cualquier equipo técnico respetaría: testing, pipelines, control de dependencias, buenas prácticas de frontend, iteración basada en feedback real.

Porque el problema nunca fue la falta de una solución.

El problema es que la solución ya existía, y funcionaba lo suficientemente bien como para no ser cuestionada.

WhatsApp no era el caos.
WhatsApp era el sistema.

Uno desordenado, sí. Difícil de auditar, también. Pero rápido, accesible, familiar. No requiere onboarding, no necesita explicaciones, no rompe ningún flujo. Vive en el bolsillo, está siempre abierto, y mezcla lo personal con lo laboral de una forma que, aunque desde IT suene incorrecta, en la práctica es extremadamente eficiente.

Y ahí es donde aparece el verdadero error.

Construí algo mejor, pero no construí algo más fácil de adoptar.

Tallercito implicaba cambiar hábitos. Implicaba salir de un entorno conocido, aprender una nueva interfaz, confiar en otra herramienta, modificar la forma en la que se comunican con clientes y proveedores. Todo eso para resolver un problema que, desde su perspectiva, no era urgente. Era molesto, sí. Pero no crítico.

Y mientras algo funcione, cambiarlo tiene un costo.

Un costo que yo subestimé.

Hoy, Tallercito dejó de ser una “solución perfecta” en busca de usuarios, y pasó a ser una herramienta disponible, sin fricción.

Hoy se puede registrar y usar de forma gratuita acá.

No como el cierre del proyecto, sino como una forma más honesta de iterarlo.

Porque al final, no gana el mejor sistema.

Gana el que la gente realmente está dispuesta a usar.