# Notas sobre construir un producto discreto

> Cuándo el soporte directo es investigación, cuándo la automatización se gana su sitio y cómo la contención mantiene un producto pequeño comprensible y de confianza.

Published: 2026-06-02 | Updated: 2026-08-08

Mole para Mac superó un pequeño hito de ventas unas tres semanas después del lanzamiento.
En lugar de escribir sobre los números, quiero anotar algunas decisiones que tomé
por el camino, porque la mayoría van a contracorriente de los instintos de un
ingeniero en activo, y son las que defendería primero. Si estás construyendo
tu propio producto, tal vez algo de esto te ahorre un desvío.

## Respondo cada correo yo mismo

Desde el lanzamiento, cada pieza de soporte la he manejado a mano: reembolsos,
reinicios de activación, devolver la diferencia de precio tras un descuento, preguntas
cotidianas. El volumen es pequeño, bastante menos del uno por ciento de los usuarios
escribe alguna vez, y podría haber montado un agente para manejarlo en media hora.
Elegí no hacerlo, por dos razones.

Primero, el soporte es donde el producto te dice la verdad. Una solicitud de reembolso
te dice por qué el producto decepcionó a alguien. Una pregunta incómoda te dice qué
parte de la app no se explica sola. Unos cuantos correos de ida y vuelta sacan a la
luz lo que el usuario realmente quería, que a menudo no es lo que pidió al principio.
Filtra eso con automatización desde el día uno y pierdes la señal justo cuando
más la necesitas.

Segundo, atender cada caso te hace fluido. Después de suficientes rondas conoces la
mejor respuesta a cada clase de problema, y sabes qué problemas debería absorber el
producto para que la pregunta nunca vuelva a plantearse. Cuando el volumen crezca y
traiga automatización, codificará esa fluidez en lugar de conjeturas.

Mi umbral para automatizar no es un conteo de tickets. Quiero que la pregunta se
repita, que la respuesta se mantenga estable y que las excepciones se comprendan.
Hasta entonces, la conversación desordenada es la investigación. Después de ese punto,
la automatización puede manejar el camino conocido y facilitar que un caso inusual
llegue a una persona.

Hasta ahora el enfoque se sostiene: no he gastado nada en marketing, el crecimiento
es de boca en boca y la tasa de reembolso está por debajo del 0,8 por ciento.

## El andamiaje puede esperar

La misma lógica aplica a la infraestructura. No monté un sistema de tickets, un
help desk ni una base de conocimiento antes del lanzamiento. A los ingenieros les
encanta construir primero la maquinaria de apoyo porque es la parte que saben
construir, y la IA la ha convertido en un trabajo de medio día, lo que la hace
más tentadora y igual de fácil de optimizar demasiado pronto. El medio día es real;
también lo es el costo continuo de cuidar un sistema que aún no necesitabas. Yo
añadiría el sistema cuando la ausencia empiece a perder solicitudes, a ocultar el
tiempo de respuesta o a hacer inconsistente la misma respuesta. Antes de eso,
la bandeja de entrada es más simple y más informativa.

## Decidir qué no construir

La diferencia entre un buen producto y uno mediocre está sobre todo en las cosas
que se niega a hacer. Qué funciones pertenecen a cada versión, qué peticiones son
necesidades reales y cuáles solo lo parecen, qué ideas genuinamente buenas aún no
pertenecen a este producto. Me he disculpado con usuarios que sugirieron funciones
buenas por sí solas, porque un Mac tiene un montón de trucos bonitos que Mole no
debería hacer. Di sí a todo y obtienes un guiso, y un guiso es difícil de mantener
y más difícil de confiar cuando se trata de borrar archivos.

Mantengo en la cabeza más o menos medio año del camino del producto: qué añade cada
versión, qué se queda fuera y dónde aterrizan las cosas para que un usuario de
primera vez las encuentre sin instrucciones. Si la primera tarea común necesita un
manual, la interfaz ha fallado a las personas a las que más quiero llegar. La
documentación sigue importando para la profundidad, los casos límite y la confianza,
pero no debería rescatar la forma básica del producto. La navaja vieja lo dice
mejor: no añadas una entidad a menos que sea necesaria.

Ahora uso tres vetos antes de que una función llegue al roadmap. No debería añadir un
timer siempre activo, un listener ni un costo de muestreo a menos que el usuario haya
entrado en la función. No debería ampliar el helper privilegiado ni pedir un permiso
nuevo solo para hacer posible una pequeña comodidad. Y no debería añadir un ajuste
cuando un valor predeterminado sereno puede decidir por todos. No son reglas universales
para el software. Son un presupuesto para este producto: el trabajo residente, el
privilegio y la configuración son formas de superficie que los usuarios tienen que
confiar para siempre.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/quiet-product-loop.webp" width="1360" height="454" loading="lazy" alt="Un bucle de decisión de producto donde la conversación directa preserva el contexto del usuario hasta que una necesidad recurrente supera las puertas de encaje de producto, confianza y seguridad, y autoexplicación antes de fijarse, programarse o rechazarse; la automatización temprana pierde la señal">
  <figcaption>Las conversaciones directas preservan el contexto hasta que una necesidad recurrente queda clara. El encaje de producto, la confianza y la autoexplicación deciden si se convierte en un arreglo, un ítem del roadmap o un no deliberado. Un buen arreglo deja menos preguntas futuras.</figcaption>
</figure>

## La posición

La posición de Mole es una frase: un cuidador silencioso para tu Mac. Limpia,
desinstala, optimiza, analiza y vigila, y por lo demás se mantiene al margen.
La ambición es simple de enunciar: si uno de cada cien usuarios de Mac se queda
con Mole, habrá resultado genuinamente útil. Hace poco algunos usuarios con
discapacidad visual empezaron a usarlo y se toparon con aristas, así que las
mejoras de accesibilidad se adelantaron a las funciones nuevas. Tengo ganas de
ver cómo se siente la app para ellos; un cuidador silencioso debería ser silencioso
para todos.

## Mantener los productos humanos en la era de la IA

La IA hizo posible gran parte de este producto. No sustituyó hablar con las personas
que lo usan, y no creo que deba hacerlo. La eficiencia es fácil de comprar ahora; el
sentimiento y la confianza entre un desarrollador y sus usuarios todavía hay que
ganarlos conversación a conversación. Tal vez así es como los productos construidos
con IA conservan su calor humano: el código se puede generar, la relación no.

Este es mi primer producto de pago, y algunas de estas decisiones pueden terminar
siendo equivocadas. Si has recorrido este camino más tiempo que yo y me ves haciendo
algo tonto, me gustaría saberlo. Cómo llegó Mole hasta aquí en primer lugar es una
historia más larga, contada en
[De un script de shell de 500 líneas a una app para Mac](https://mole.fit/es/blog/the-story-of-mole).

---

Canonical HTML page: https://mole.fit/es/blog/notes-on-building-a-quiet-product
Blog index for agents: https://mole.fit/es/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
