Política de entrega: plazos y qué hacemos cuando algo falla

El miedo que más escucho de los fundadores no es sobre tecnología. Es sobre dinero: “¿y si pago y el estudio desaparece?”. Es un miedo justo. Mucha gente ya pagó un anticipo, recibió promesas y se quedó sin producto en línea.

Una promesa de palabra no resuelve ese miedo. Una política escrita, sí. La inspiración de esta página vino de Linear, la herramienta de gestión de proyectos, que publicó en septiembre de 2025 su política de cero bugs, con plazos y cifras. Esta es nuestra versión para la entrega de producto.

Lo que Linear hizo con los bugs

El texto, firmado por Tuomas Artman y Sabin Roman, cuenta cómo la empresa decidió dejar de acumular bugs. Los puntos principales:

• Vaciar la cola. Linear tenía unos 175 bugs abiertos. El equipo pausó todos los demás proyectos durante tres semanas para corregirlo todo.
• Plazos fijos. Los bugs de alta prioridad tienen 48 horas para corregirse. Los de baja prioridad, 7 días.
• Sin backlog. Quien recibe el bug decide: lo corrige o lo marca como “no se corregirá”. Mandarlo a una lista de espera no es una opción.
• Rutina diaria. Los ingenieros empiezan el día por los bugs que tienen asignados.

El resultado: más de 2.000 bugs corregidos en un año, más de 700 en los últimos tres meses, y bugs llegados desde soporte resueltos muchas veces el mismo día. Cuando el equipo debatió abandonar la práctica, nadie quiso. En palabras de los autores: “Nobody could imagine going back” (nadie se imaginaba volver atrás).

Por qué publicar una política de entrega

Lo más interesante que hizo Linear no fue corregir bugs. Fue escribir la regla y publicarla. Una regla escrita saca la decisión del humor del día y la pone delante del cliente.

Para un estudio, lo equivalente es decir, por escrito y antes del contrato, qué pasa en cada paso: cuánto cuesta, cuándo estará listo, qué recibes y qué hacemos cuando algo sale mal.

Nuestra política de entrega

Estos compromisos valen para todos nuestros proyectos y quedan por escrito en el contrato.

1. Precio cerrado tras el diagnóstico. No damos precio antes de entender el problema. Tras el diagnóstico, el precio es un número, no un rango de horas.

2. Plazo por escrito en el contrato. La fecha de entrega va en el contrato. Lo que pasa si el Studio causa un retraso también queda por escrito, antes de firmar.

3. Un solo equipo. Diseño y código quedan en manos de nuestro equipo, del diagnóstico a la publicación, para que el plazo sea realista.

4. Pago ligado a entregas. Los pagos siguen los pasos del proyecto, y cada paso tiene una entrega definida en el contrato.

5. Ves el producto pronto. Trabajamos en ciclos cortos, y cada ciclo termina con una versión que puedes navegar.

6. Todo es tuyo. El código, los archivos de Figma, los accesos y la documentación quedan a tu nombre.

7. Agente de IA desde el primer día en línea. Cada sistema que entregamos sale con un agente de IA que se ejecuta a diario, señala fallos, sugiere mejoras y comprueba que los datos tengan sentido.

Qué pasa cuando algo falla

El software falla. La diferencia está en lo que pasa después. Inspirados en Linear, organizamos la respuesta por gravedad:

• Crítico (sistema caído, pérdida de datos, cobro erróneo): primera respuesta en menos de 2 h en horario laboral, y la corrección pasa por delante de todo lo demás.
• Alto (funcionalidad principal con error, sin alternativa): la corrección pasa por delante de las demás tareas del equipo.
• Bajo (error visual, detalle con alternativa): la corrección entra en el siguiente ciclo de entregas.

Durante cuánto tiempo estas correcciones quedan cubiertas sin costo tras la entrega se fija por escrito en el contrato. Después de ese período, el producto puede seguir en el servicio de Evolución continua.

El agente diario ayuda a acortar el primer paso, que es saber que algo falló. Señala fallos y comprueba cada día que los datos tengan sentido, lo que en muchos casos permite actuar antes de que el problema llegue a tu usuario. Lo que encuentra llega en un informe para ti y para nuestro equipo de desarrollo.

Qué cambia esto para ti

Usa esta página como lista de verificación, con nosotros o con cualquier otro proveedor, junto con las preguntas antes de contratar un estudio. Antes de firmar, pregunta:

1. ¿El precio es cerrado? ¿Llegó después de entender el problema?
2. ¿El plazo está en el contrato? ¿Qué pasa si hay retraso?
3. ¿Cuántos proyectos atiende el equipo a la vez?
4. ¿Cómo se vincula el pago a las entregas?
5. ¿El código, el diseño y los accesos son tuyos al final?
6. ¿Qué pasa cuando algo falla, y en cuánto tiempo?

Quien responde por escrito tiene un proceso. Quien responde solo de palabra te está pidiendo confianza.

Cómo lo hacemos en el Studio

Estamos en esto desde 2014, con más de 600 proyectos para clientes en 13 países. Dos plazos de casos: LCX quedó en línea en 29 días, unificando el sistema de más de 10 países de Sudamérica. AI Vou Eu, SaaS de turismo con IA, salió en línea en 4 semanas.

Esta política se actualizará cada vez que cambie un compromiso, con fecha. Si quieres lanzar tu SaaS con estos compromisos en el contrato, nuestro servicio de desarrollo de sistemas a medida y SaaS empieza por el diagnóstico.