En la segunda clase del curso de Lovable vamos a transformar una plantilla en una aplicación propia y a planificar bien nuestros prompts.
Modificar una plantilla puede darnos una falsa sensación de avance si solo cambiamos textos, colores o detalles superficiales. La clave está en entender que una cosa es maquillar una aplicación y otra muy distinta es adaptarla de verdad a la lógica que necesitamos. Cuando trabajamos con una herramienta de este tipo, el resultado depende mucho de cómo pensamos antes de pedir. Si no definimos bien la estructura, los datos y las funcionalidades, acabaremos con una app incoherente por dentro, aunque por fuera parezca correcta. Por eso esta sesión es especialmente importante: aquí empezamos a trabajar con criterio, a detenernos antes de escribir y a construir sobre una base sólida.
Vamos a convertir una plantilla de eventos en una aplicación de gestión de ideas de contenido, que será el proyecto práctico del curso. Antes de lanzar ningún cambio, definiremos qué debe poder hacer la app, qué campos tendrá cada idea y cómo queremos que se comporte. También veremos la diferencia entre ejecutar directamente y utilizar el modo plan, revisaremos la propuesta de cambios antes de aceptarla y comprobaremos cómo la plataforma modifica rutas, componentes, base de datos y navegación para adaptarse al nuevo contexto. ¡Vamos a verlo!
Pues ya lo vemos, hemos conseguido pasar de una plantilla adaptada solo en apariencia a una aplicación que realmente empieza a responder a la lógica que necesitamos. Ahora ya no tenemos una estructura de eventos con textos cambiados, sino una base pensada para gestionar ideas de contenido, con sus propios estados, sus formularios y sus páginas. Lo más valioso no ha sido solo el resultado, sino el proceso de planificación previo que nos ha permitido decidir mejor qué pedir y cómo pedirlo.
Uno de los puntos más interesantes de esta clase ha sido entender el valor del modo plan. En lugar de lanzar cambios grandes a ciegas, hemos podido ver antes qué iba a tocar la herramienta, qué archivos pensaba modificar, qué componentes iba a eliminar y cómo pretendía reorganizar la aplicación. Esto resulta muy útil cuando hacemos cambios estructurales, porque nos da una capa de control que evita romper el proyecto innecesariamente. Aprender a revisar ese plan nos sitúa en una posición mucho más profesional.
También hemos trabajado algo esencial: pensar la arquitectura antes de empezar. Hemos definido acciones concretas, como crear, listar, editar y eliminar ideas, y hemos decidido qué campos debía tener cada una. Ese pequeño ejercicio previo, aunque parezca simple, marca una gran diferencia porque convierte un prompt genérico en una instrucción clara y útil. En herramientas de este tipo, esa claridad es media aplicación.
Como ejercicio práctico, podemos coger otra plantilla distinta y repetir el mismo proceso: primero definir qué queremos conseguir, luego enumerar qué funcionalidades mínimas debe tener la aplicación y finalmente pedir el cambio utilizando el modo plan antes de ejecutarlo. Después, podemos revisar el código generado, identificar qué carpetas contienen las páginas, los componentes y la base de datos, y comprobar cómo se ha reorganizado todo.
Si surge cualquier duda mientras trabajamos con la planificación, los cambios estructurales o la lectura básica del proyecto, siempre podemos contar con el equipo de soporte que está al otro lado de la intranet para ayudarnos a seguir avanzando con seguridad.