De idea a producto en 30 días: lo que aprendimos construyendo Herrero Pro

Herrero Pro empezó un lunes a la mañana con una pregunta sencilla: ¿por qué el taller de herrería de nuestra propia empresa sigue haciendo presupuestos en Excel?

Cuatro semanas después, teníamos un producto en producción. Hoy lo usan más de 2.400 talleres en toda Argentina.

Acá está todo lo que aprendimos.

El error más común en el desarrollo de MVP: construir demasiado

Cuando empezás a pensar en un producto, la lista de features crece sola. Sincronización en la nube, aplicación móvil, integraciones con sistemas de contabilidad, reportes avanzados, múltiples usuarios, roles y permisos...

Todo eso tiene sentido. Y todo eso va a retrasar el lanzamiento seis meses.

La pregunta que nos hicimos fue diferente: ¿cuál es la única cosa que este producto tiene que hacer bien para que alguien lo use?

Para Herrero Pro, la respuesta era: generar un presupuesto profesional en PDF en menos de dos minutos.

Todo lo demás vino después.

Offline-first no fue una decisión técnica: fue una decisión de producto

Los talleres de herrería trabajan en galpones. Muchos tienen conexión a internet intermitente o directamente no la tienen. Un producto que requiere conexión permanente no sirve para ese contexto.

Decidimos desde el día uno que los datos vivirían en el navegador (localStorage) y que el producto funcionaría completamente offline.

Esto simplificó radicalmente la arquitectura: no había backend que mantener, no había base de datos en la nube que costara dinero, no había problema de latencia. Era un producto que vivía en el dispositivo del usuario.

La desventaja — no hay sincronización entre dispositivos — se convirtió en el feature principal del plan siguiente. Las restricciones te dan el roadmap gratis.

Lo que aceleró el desarrollo

Conocíamos el problema desde adentro. No tuvimos que hacer research de usuarios porque éramos el usuario. Cada decisión de diseño tenía una respuesta inmediata: "¿funciona para nuestro taller? Sí/No." Decidimos temprano qué no íbamos a construir. No había app móvil en v1. No había backend. No había autenticación de usuarios. No había reportes avanzados. Esas decisiones liberaron semanas de desarrollo. El diseño siguió a la función. No empezamos por los mockups. Empezamos por los flujos: ¿qué hace el usuario cuando llega? ¿Qué necesita para crear su primer presupuesto? La interfaz siguió esos flujos, no al revés.

Lo que haríamos diferente

Lanzar antes. Esperamos tener "suficientes features" para lanzar. En retrospectiva, con el core de cotizaciones funcionando podríamos haber lanzado diez días antes y recolectado feedback real de usuarios reales. Hablar con más herreros antes de construir. Conocíamos el problema de nuestro taller. No sabíamos si era representativo del sector. Resultó que sí — pero podríamos haberlo validado antes de escribir una línea de código.

La lección central

Un producto que resuelve un problema específico de una industria específica tiene una ventaja que los productos genéricos nunca van a tener: los usuarios sienten que fue hecho para ellos.

Herrero Pro no tiene todas las features de un ERP. Tiene exactamente las features que un taller de herrería necesita, en el orden en que las necesita, con el vocabulario que el sector usa.

Eso no lo podés construir sin entender la industria desde adentro.

---

¿Tenés una idea para un producto vertical? Contanos de qué se trata.