Cuándo pedir ayuda a un desarrollador con tu proyecto de vibe coding

Construir una app con Lovable, Bolt, Cursor, v0, Replit o Claude Code es una forma legítima de empezar. Te permite probar una idea en días, mostrarla y aprender muchísimo por el camino. Muchos productos que hoy funcionan nacieron como un prototipo imperfecto.

Pero llega un momento en que la IA sola ya no te lleva más lejos. Pasa con todas las herramientas. Algunos problemas necesitan a alguien que entienda el sistema completo. Esta guía te ayuda a reconocer ese momento y a prepararte para que la ayuda sea rápida y útil.

Señales de que conviene pedir ayuda

No todas significan que algo está mal. Pero si te reconoces en dos o tres, probablemente es hora:

1. Llevas días con el mismo error. Le has pedido a la IA que lo arregle muchas veces y vuelve a aparecer.
2. Arreglas una cosa y se rompen otras. Cada cambio tiene efectos que no esperabas.
3. Te da miedo tocar la app. Ya no sabes qué hace cada parte y prefieres no pedir nada nuevo.
4. Vas a manejar datos o dinero de verdad. Usuarios reales, pagos, información personal o de salud.
5. No logras salir de la vista previa. El dominio, el hosting o las variables de entorno no terminan de funcionar.
6. Necesitas integraciones serias. Stripe con webhooks, correos transaccionales, APIs de terceros, permisos por rol.
7. La app se volvió lenta cuando empezó a tener más datos o más usuarios.
8. La IA empieza a perder el hilo. El proyecto creció tanto que las respuestas ignoran partes importantes o contradicen cambios anteriores.

Si tu caso es el primero o el segundo, antes de pedir ayuda vale la pena seguir los pasos de cómo saber qué se rompió en tu app. A veces lo resuelves tú, y si no, ya tendrás mucha información útil.

Qué preparar antes de escribir

Cuanto mejor llegue la información, menos tiempo (y dinero) se gasta en entender el problema. No necesitas usar términos técnicos.

1. El enlace a tu app

La versión publicada y, si es distinta, la vista previa. Si la app tiene login, crea un usuario de prueba con datos ficticios para quien te ayude, en lugar de compartir tu cuenta personal.

2. Una descripción clara del problema

Usa este formato sencillo:

• Qué intentas hacer: "que mis clientes paguen la suscripción mensual".
• Qué esperas que pase y qué pasa en realidad.
• Pasos para reproducirlo, uno por línea.
• Desde cuándo pasa y qué cambiaste justo antes.
• Qué ya intentaste, incluidos los prompts que no funcionaron.
• Capturas o un video corto de la pantalla, y el texto de los errores de la consola si los tienes.

3. Con qué está hecha

La herramienta (Lovable, Bolt, Cursor…), el backend (Supabase, Firebase, otro), dónde está publicada y qué servicios externos usa (Stripe, correo, IA). Si no lo sabes todo, no pasa nada: con el enlace y el repositorio se puede averiguar.

4. Acceso al código, de forma segura

Lo más práctico es que el proyecto esté en GitHub. Lovable y Bolt, por ejemplo, permiten conectar o exportar el proyecto a un repositorio. Para dar acceso:

• Invita a la persona como colaboradora del repositorio o miembro del proyecto (GitHub, Supabase, Vercel), en lugar de compartir tus contraseñas.
• No envíes claves ni contraseñas por chat o correo. Si alguna vez lo hiciste, rótalas cuando termine el trabajo.
• Retira los accesos cuando ya no hagan falta. Es tu proyecto y tú decides quién entra.

5. Prioridades y límites

Qué es urgente y qué puede esperar, si hay una fecha que importa (una demo, un lanzamiento) y qué no se puede cambiar (el diseño, una integración que ya usan tus clientes). Esto evita sorpresas.

Qué esperar de una buena ayuda

Cada equipo trabaja distinto, pero hay cosas que deberías poder esperar, y que nosotros consideramos básicas:

• Primero un diagnóstico. Antes de cambiar código, alguien revisa tu app y te explica en palabras simples qué está pasando y qué opciones hay.
• Precio claro antes de empezar. Te dicen qué se va a hacer y cuánto cuesta antes de tocar nada. Si no te convence, puedes decir que no.
• Cambios que puedes ver. Trabajo en tu repositorio, con commits que muestran qué se modificó, para que no dependas de nadie.
• Explicaciones, no solo arreglos. Lo ideal es que salgas entendiendo por qué pasó, cómo evitarlo y cómo pedirle mejor a la IA la próxima vez.
• Respeto por lo que construiste. Nadie debería hacerte sentir mal por cómo está el código. Rehacer todo desde cero casi nunca es la primera respuesta.
• Puedes seguir usando tu herramienta. Después de la ayuda, la idea es que sigas construyendo con IA, solo que sobre una base más firme.

Errores comunes al pedir ayuda

• Esperar a que el problema sea enorme. Un bug pequeño hoy es más barato que tres bugs mezclados la semana que viene.
• Seguir pidiendo cambios a la IA mientras otra persona revisa el proyecto: dos manos tocando el mismo código a la vez generan conflictos.
• Enviar "no funciona" sin más. Los cinco minutos que tardas en describirlo bien ahorran horas.

Cuéntanos qué está pasando

En Devonauts ayudamos a personas que construyeron su app con IA y se quedaron atascadas: rescate y depuración, revisiones de seguridad, salida a producción, integraciones y sesiones en vivo para aprender en el camino. Con el enlace de tu app y una descripción, te respondemos con un primer diagnóstico y un precio antes de empezar. Conoce el rescate de apps hechas con IA o escríbenos directamente.