Workshop 1: Cómo ganar en una Hackathon Web3

Transcript

Buenas tardes con todos, vamos a dar inicio al primer workshop. Como saben, eh la hackaton ya arrancó desde ayer. Aún tienen la posibilidad de inscribirse hasta el 3 de agosto. Durante todo el día. Para que ustedes puedan unir a personas a su equipo o unir nuevos equipos incluso a la hackaton, en caso de que haya más personas, entidades interesadas. La importancia de esta hackaton y la problemática a abordar por parte de ustedes.

Es que planteen. Un problema solución. Que ten, que sea viable y que genere gran impacto en la sociedad, ya sea en el país donde estén concursando, ya sea eh el sector en el cual ustedes estén, puede ser agro, puede ser administración economía. Tema de DeFi. Eh, tema de retail. Y muchos otros, ¿no? Entonces. Eh, la idea es que ustedes planteen esta.

Este reto para ustedes mismos y puedan implementarlo con las herramientas de árbitro ¿no? Ya hemos visto en el bootcamp. Lo que se puede plantear, parte de ello el conocimiento lo hemos tenido incluso desde el año pasado. Entonces, tienen toda esa formación ya lista en la plataforma en la cual ustedes se han inscritos una vez que han sido aceptados. En caso no tengan acceso. Eh, les debe haber llegado un correo y en caso no haya, no les haya llegado un correo, pues escríbanme por interno en el Discord. Para ver este, para solucionar ello, ¿no?

Entonces. Dicho eso. Déjenme. Perfecto. Pues, otra información clave es que vamos a tener varios workshops. Eh, les recomiendo que aprovechen los workshops. Con ideas ya listas, ¿no? Hoy vamos a ver grandes tips sobre cómo ganar en la hackaton y vamos a tener durante la semana también algunos de producto, otros de ecosistema web 3 en general, otros técnicos, entonces, hay diversos aspectos los cuales ustedes van a poder integrar eh todos los conocimientos que van adquiriendo ¿no?

Tip 1, entonces, ver los videos que están en la plataforma y tip 2 venir con ideas frescas a cada workshop, estoy seguro que lo van a a necesitar o aprovechar. Y como último paso, eh ya están habilitados en la plataforma también para que puedan realizar las mentorías. Cada mentor va a ir habilitando poco a poco, van a ir aumentando los mentores en la plataforma y ustedes van a poder ir aprovechándolos, ¿no? En caso, por ejemplo, eh hay algún problema con la plataforma, igual por Discord estamos solucionando.

Entonces, eh bien, dejo de de compartir para poder iniciar el espacio. Entonces, para comenzar con esta sección, eh te doy el pase, Ian, eh para que puedas iniciar con el workshop. Vale, vale, muchas gracias. Bien, nomás me pueden confirmar si se ve

la pantalla, por favor. Bueno, la presentación. Vale, pues, un es un gusto estar eh por acá de nuevo, el año pasado igual pude estar presente. Igual eh pues bienvenidos a todos y pues yo voy a dar el workshop de cómo ganar un hackathon web3. Bien, pues vamos a comenzar. Primero pues me presento, yo soy Brian Espinosa, yo soy de de México. Soy parte de una comunidad eh mexicana en la universidad que se llama la UNAM, que es la universidad más grande de de México.

Eh llevo aproximadamente dos años ya desarrollando proyectos y soluciones dentro de lo que es el tema de de blockchain. Actualmente eh estoy trabajando en una startup que se llama Cypher Labs. Soy embajador de Tangem y de la wallet que es una wallet fría y y de Stellar que es una blockchain. Eh sigo estudiando, actualmente sigo estudiando la ingeniería de en redes digitales y pues como dato adicional me me encantan los gatos, tengo tengo muchos gatos.

Esto, esta información me gustaría hacer un paréntesis porque quiere yo eh comencé mi trayectoria en web3 en blockchain como desarrollador justamente en una hackathon. Yo comencé en una hackathon hace dos años en donde yo no sabía absolutamente nada, no sabía en qué era un contrato inteligente, sabía muy poco de blockchain y lo único que sabía era de criptomonedas, era lo único que yo sabía. Y pues gracias a a ese primer impulso de participar en una hackathon fue en el momento en el que pues a mí me llamó la atención y sobre todo se me abrieron diferentes puertas por la curiosidad y las ganas de construir cosas.

Entonces pues justamente con esto es esta parte, ¿no? De que y ustedes ya están ganando por atreverse a participar. Hay muchas personas que les da pena, que dudan de sus conocimientos o de muchas otras cosas. Pero pues actualmente tenemos muchísimas herramientas que nos van a que les van a facilitar el trabajo para realizar algún proyecto ganador. Y pues ahorita es muy importante que ustedes se sientan seguros de pues de estar participando y que también se sientan seguros de charlar, porque eso va a ser muy importante y lo vamos a ver un poco más adelante.

Entonces, comenzando un poco con esto, en no hay reacciones y creo que sí, no sé si pueden eh mandar alguna reacción los que es su primer hackathon. Bueno, no veo reacciones. Ah, no, sí, hay un Geraldín, William. Muy bien, muy bien, entonces, de varias personas y es su su primer hackathon, igual aquí en el chat veo a José Rivas, Gaili, entonces, pues esto es muy importante para ustedes. Vamos a empezar.

Antes de empezar con la teoría y con los tips, vamos a recapitular un poco de dónde nacieron los hackatons. Porque es importante entender qué es en sí un hackaton y de dónde viene y cómo ha evolucionado. El vamos a decir que el primer hackaton que en el que se tuvo registro de cierta manera que que sucedió fue en 1999, que fue un hackaton de Open BSD, que fue un hackaton para para crear eh un sistema operativo basado en Linux.

Justamente en este en este evento, que de hecho no se llamaba hackaton, nació el término de hackaton, porque antes era eh code-ton, era fest hack festival, algo así eran, tenían muchos otros nombres. En este caso, en 1990, fue en una conferencia de Sun Microsystems. Entonces, vamos a decirlo que este podría ser como el primer momento en el que nació el término de una hackaton. Después venimos por el 2005-2007 en donde justamente es un punto muy clave, de hecho, no sé si alguien de aquí ya haya visto la película de The Social Network.

Que justamente anda narrada la historia de Facebook, ¿no? Y justamente ahí lo menciona que Mark Zuckerberg cuando estaba desarrollando Facebook en una eh edad temprana hizo una hackaton con sus amigos en la universidad en donde pues estaban bien estaban participando para ver quién es el que podía sacar nuevos features o nuevos no sé decir que nuevas cosas para la aplicación. Entonces, desde este momento igual ya se estaba como que familiarizando este término y sobre todo se estaba volviendo un poco más popular este tipo de eventos en donde diferentes personas, simplemente por diversión era que buscaban hacer una hackaton para ver y competir para ver quién programaba

mejor, para quién sacaba las mejores ideas y etcétera. Justamente eh como aquí dice Facebook y otras startups lo adoptaron para prototipear rápido en en puertas o en vamos a decirlo que en un entorno cerrado, que no fuera abierto. Es más, después seguimos con el 2010, que fue ahí fue como un punto importante sobre las hackatons debido a que pues sabemos de que el nombre es un poco estereotipado, que nada más se escucha, yo, por ejemplo, yo cuando escuché el término de hackaton dije, nos van a hackear, vamos a hackear o algo así, ¿no?

Eh hackear en el sentido de vulnerar eh computadoras, a sacar virus, etcétera, ¿no? Pero pues sabemos de que el en sí el hack ese término no no simplemente implica toda esta parte de vulnerar cosas, sino simplemente es como codear. Entonces, este fue un punto muy importante porque en el 2010 hubo un hackathon, como aquí se ve, biohackathon, que fue justamente para desarrollar soluciones en la área médica y esto fue en Japón.

Entonces, justamente esta eh este evento fue muy importante, vamos a decir que para toda esta línea del tiempo que llevamos de los hackathons, porque fue muy importante para las áreas médicas en Japón, porque sí salieron soluciones bastante buenas que se utilizaron y se siguen utilizando. Entonces, justamente esta parte en donde en el 2010 el formato se abre al público, en donde en vez de ser privado, un poco más, en vez de ser más para diversión, fue más para universidades, comunidades tech, para crear soluciones reales, que es como la narrativa que se lleva ahora.

Y pues, hoy, hoy existen hackathons de muchísimos temas, en muchísimos ecosistemas, con muchísimas narrativas. En, por ejemplo, pues ahorita estamos en el en el hackathon de de Lima, pero también hay hackathon, el hackathon más grande de de Ethereum, pues esos son los Devcon net, los Devcon, que, por ejemplo, el próximo va a ser en Mumbai, si no me parece, en India. Y ese, pues, es el encuentro más grande de desarrolladores. Y también aquí voy a hacer un paréntesis un poco grande, debido a que muchas veces las personas solamente se cierran a que un hackathon debe ser al 100% al desarrollo, a saber

programar, a saber código, a saber cómo la la subir una aplicación a una webpage etcétera. Cuando en realidad es que no. Sí es muy importante la parte técnica, no, sí es importante, pero no es el 100%, es el 50%, vamos a ponerlo así, debido a que el otro 50% se debe de complementar con parte de marketing, con parte del storytelling, con parte de de diseño ¿no? Entonces, eh igual que lo vamos a ver un poco más adelante, es muy importante tener esto en mente y empezar a construir equipo o si ya tienen equipo, denotar los roles que va a tener cada

uno. Y esto también. Antes de estudiar una idea, estudien el hackathon. Sabemos que ahorita, pues ya empezó el hackathon, pero mi recomendación, que lo pueden utilizar, eh no solamente en este hackathon, sino en futuros hackathons que vayan a a participar, es que antes de que estudien una idea, estudien el hackathon. Un ejemplo, estamos en el hackathon de Eth Lima del 2026. Tenemos que principalmente está Arbitrum como como sponsor, ¿no?

Entonces, justamente como aquí dice, sponsors. ¿Qué es lo que ellos buscan y qué bounties ofrecen? La qué tecnología se van a utilizar, qué stack, qué chains, qué blockchains apoya el evento. Las herramientas que pueden existir, los SDKs, las APIs y los créditos disponibles para usar. Y esto, pues, es dependiendo de cada hackathon, no hay hackathons que que dan eh créditos para Amazon Web Service, créditos para alguna inteligencia artificial como Cloud, ChatGPT, etcétera. Y los jueces. También es un poco importante que que conozcan o que tengan como esta parte de saber quiénes son los jueces,

que en qué otros hackathons han participado anteriormente y, pues, a quién ha y a quién ha premiado antes. Todo esto, eh yo creo que es muy importante porque primero se tiene que explorar el, vamos a decir que El environment en donde ustedes van a estar participando. Porque ustedes al empaparse de esto Ustedes van a saber qué es lo que buscan, qué es lo que ustedes pueden dar Y pues qué es lo que ustedes de deben de utilizar para acercarse más a una victoria.

Esto es algo muy muy importante también. Y justamente como lo estaba comentando antes Hablar con los mentores Es muy importante. Muchas veces eh yo lo he visto Aproximadamente yo ya he participado en más de 20 hackatons, aproximadamente cinco si han sido internacionales y de esos 15, 10 los los he ganado, no con un primer lugar Pero sí.

Y vamos a decir lo que esto es un poco de mi fórmula Como para que he llevado algunos hackatons en los que yo he participado. Que igual cuando uno está participando en una hackaton Igual aparte de estudiar la hackaton Lo que se tiene que hacer es demasiado networking y aquí es en una parte en donde muchas personas Vamos a decir que flaquean. Está bien y está mal. Está bien porque se entiende de que hay personas pues que les da pena, de que Los nervios también, ¿no? Yo creo que a todos nos ha pasado, les va a pasar a los primeros que vayan a participar, que sean esos nervios que de decir Ay, voy a ganar, no voy a ganar, ay, mi idea es buena o no es

buena. Y es normal. Pero Justamente de las primeras slides que decía de que ustedes ya están ganando Ustedes deben de de ponerse en esa en ese pensamiento de que ya dieron un paso Están participando. Ahora deben de dar el siguiente paso para quitarse un poco de de la timidez para poder hablar con con los mentores, con las personas que estén en participando dentro del hackaton. Sabemos que ahorita es en línea, pero está el Discord y entonces ahí igual se puede hacer demasiado networking. Yo creo que en Discord también es demasiado fácil hacer eh el networking, platicar con las demás personas, porque ya es un medio digital y pues también están

las partes para hacer las las llamadas, si no mal recuerdo, parece. Entonces, justamente es muy importante que conozcan a los a los jueces, que hablen con los mentores y que igual eso es muy importante, que pregunten todo lo que tengan duda. Mmm. Es como esta esta frase que que se me vino a la mente ahorita, el que pregunta no es tonto, es tonto el que no pregunta. Entonces, de verdad, cualquier duda que tengan, aunque sea como ustedes lo a veces lo piensen, aunque pueda ser muy básica, aunque pueda ser muy muy básica, muy muy atrasada, eh como sea, ustedes lo deben de preguntar,

porque si ustedes se quedan con esa mínima duda, aparte de tener la duda, se van a quedar con esa como con ese vacío de de decir, ay, pero si se hacía así, no se hacía así, esto sí se ocupaba o no se ocupaba, etcétera, ¿no? Que pueden pasar en muchísimas situaciones adentro de un hackaton. Igual y la siguiente parte muy importante es el feedback. He notado eh hubo un hackaton aquí en México hace unos meses que fue de la blockchain de Stellar y yo estuve aquí igual como mentor.

Y ahí vi algo muy importante, y es que cuando nosotros le damos feedback a los chicos y la verdad, pues el feedback muchas veces es honesto y debe de serlo. Entonces, a veces los chicos decían, "Oh, sí, como que se ponían cabizbajos porque sentían que su idea o su proyecto estaba mal, se se se sentían de cierta manera atacados porque el feedback no fue lo que ellos gustaban o querían que escuchar, ¿no? De, "Ay, es que esta idea está muy bien, eh ponle o añádele esto, etcétera, ¿no?

El feedback es bueno y muchas veces también es bueno que recibas feedback negativo de cierta manera. ¿Por qué? Porque aquí te abre la puerta a que tú puedas pivotear eh tu idea. ¿Qué es un pivote? El pivote es de que tú tienes una idea, ¿no? Yo voy a poner, por ejemplo, una veterinaria para a gatos. Ah, pero estoy en México, en en México sí hay gatos y y mi empresa la mando a a Perú. Y en Perú casi no hay gatos, nada más es un ejemplo lo que estoy poniendo. En Perú hay más eh llamas, eh alpacas, creo que es lo que hay más allá, bueno, el animalito, no creo que sí son llamas, no sé si me pueden eh ahí corregir.

No estoy muy empapado en esto. Entonces, eh siguiendo con el ejemplo, ese es un pivote, de pasar de una veterinaria para gatos a pasar una veterinaria para las alpacas. Porque es lo que más se puede sacar provecho de la idea. Entonces, justamente con esta parte del feedback es muy importante que ustedes hasta que aunque no sean con los mentores, que sea con los demás chicos que ustedes están participando y ya están en su propia casa. Que si ustedes están hackeando, le pregunten a su mamá, "Oye, mamá, ¿qué te parece esta idea, no?" Y esa es una parte muy importante y un consejo que le he dado a varias personas de que le platiquen primero la idea a su mamá, a su abuelita y si su mamá y su abuelita

lo entienden, puede que su idea esté muy bien hecha para que todos lo puedan entender y utilizar. Eh, hago igual mención de que en cualquier momento pueden abrir el micrófono para si tienen alguna duda, algo que que expresar, está totalmente abierto el micrófono para que puedan charlar también. Siguiendo con esto, viene la parte de la comunidad. El equipo de al lado, hoy puede ser su proyecto, su startup, su próxima empresa.

Entonces, esto es importante porque tienen que definir bien sus roles desde un principio. Lo que pasa muchas veces igual en las hackatons es de que dicen, "Mmm, oye, vamos a todos vamos a programar." Y dicen, "Bueno, okay." Pero después ya cuando terminan de programar, de codear el proyecto, al final quién va a hacer la la presentación, al final quién va a hacer el diseño de la página web si es que tiene, al final quién va a hacer el pitch. Entonces, eh esto es muy importante que desde un principio definan bien los roles. Y bueno, también se vale, ¿no?

Eh, esto igual me gusta comentarlo, también se vale el decir, "Yo posiblemente estamos para aquí para divertirnos, para aprender", que eso es muy importante. En una hackaton se aprende lo que posiblemente no no se puede aprender en en 6 meses. Entre justamente esta presión de entregar un proyecto y todo esto, yo creo que aprendes demasiadas cosas, se aprenden demasiadas cosas en unos tres, cuatro días para la creación de tu proyecto. Entonces, también se vale decir eso, pero si lo que ustedes quieren es como justamente aumentar sus posibilidades de ganar la hackaton, eh posiblemente sí sea mejor seguir este como estas partes en donde tienen que definir bien la idea, definir bien los

roles de su equipo para que todos los entregables pues se se realicen de manera satisfactoria. La siguiente parte es la visibilidad. Aquí dice, "La gente recuerda a quien pregunta, no a quien se esconde en su laptop." Que era lo que les comentaba. No no tengan pena, posiblemente varios lo van a tener, pero ahora sí que tomen la el coraje de poder hablar con los mentores, de poder hablar con otros equipos en el hackathon y con poder hablar con todas las personas con las que ustedes puedan. La visibilidad también es una parte muy importante de los hackathons.

Eh volviendo a lo que yo les comentaba de la hackathon de aquí en México, igual en esa hackathon un equipo era un equipo de que nunca nunca había tocado eh Solidity, nunca había programado para la Ethereum Virtual Machine, nunca había programado nada en sobre blockchain, para nada. Sí eran técnicos, sí saben programar en Java, etcétera, pero jamás habían programado nada para blockchain. Y ellos se llevaron un primer lugar en ese hackathon. Y que qué fue lo que pasó, primero hablaron con todos los mentores, pidieron feedback y sobre todo tuvieron la visibilidad. Desde el desde el día uno ellos eh hicieron un Twitter y un Instagram para su proyecto y

empezaron a subir fotos de de ellos mismos pues hackeando adentro del hackathon, de mandando fotos de aquí estamos eh sacando el nuevo la nueva funcionalidad de nuestro proyecto de la hackathon, etcétera, etcétera etcétera. Entonces, la visibilidad también es demasiado demasiado bueno y demasiado importante en la que donde ustedes nada más con un post que hagan en Twitter, en Instagram, ustedes ya van un pasito más adelantado porque esto ya les abre diferentes eh partes muy importantes para su proyecto.

Igual con esta parte del del proyecto, yo creo que algo muy importante que no puse en la en la presentación, es posiblemente, como hemos estado hablando de que sea un proyecto que solucione algo real, yo creo que también lo más importante es posiblemente tener historias de usuario. Yo creo que si ustedes van a hacer algún proyecto, vamos a hablarlo sobre pagos transfronterizos o sobre cualquier tipo de índole, que tengan mínimo una un vídeo o aunque sea un una nota de voz que entrevistaron a una persona.

Yo creo que con solamente hacer ese gesto y presentarlo en la demo, ponerlo en su documentación de hicimos la entrevista a un usuario que les valide su idea, eso ya es demasiado muy bueno, es muy bueno, porque eso les da la la validación a su proyecto de que una persona del mundo exterior lo validó y no solamente la inteligencia artificial, que muchas veces tampoco está mal, que muchas veces eh se pide la validación a la inteligencia artificial, pero pues la inteligencia artificial está muy sesgada y puede alucinar, ¿no?

Que los alucinamientos en la inteligencia artificial, esta parte es en donde se inventan los datos o simplemente, como se ha visto, la inteligencia artificial pues le da la razón al al usuario ¿no? Entonces, tener una entrevista, eh ya sea se en audio eh o en vídeo, que en vídeo sería un plus demasiado grande, les da más ventaja y les da más posibilidades de ser más vistos y sobre todo de que su proyecto tenga más atracción para los para las personas que estén de jueces. De momento no sé si tengan eh alguna duda, algún comentario sobre esto.

Pueden poner igual dudas o cualquier cosa en en el chat y los los leo. Bien siguiendo. Aquí es una parte muy importante, el mito versus la realidad. Señoría disculpe. Sí sí. Eh Bueno, no sé si estaba como regla, pero o sea, ya que estamos creando proyectos, podríamos, o sea, publicarlo en las redes sociales y a la larga podríamos, o sea, si es que son muy buenos, poder iniciar como una startup con ese proyecto. O sea, ¿estaría válido si lo hiciéramos en este concurso?

Yo creo que sí. No creo creo que no hay como una regla que sea de hackathon, que sea como que el proyecto nada más se quede aquí dentro de la hackathon. Y justamente creo que sí es muy muy bueno lo que lo que tú dices, Alexander, de hacer un un ejemplo, no, subir las publicaciones y si el proyecto llega a ganar, seguirle, ¿no? Y aún así, si no gana y a ti te gustó demasiado la idea, poder seguirle la idea. Pero sí es demasiado demasiado bueno lo que tú dices, de subir la publicación y si en algún momento hacerlo una startup.

Justamente así me así Leo lo hice con mi equipo. Eh lo que yo les decía, soy CPU de Cipher Labs. Cipher Labs nació en un hackathon hace 9 meses. Era un proyecto de hackathon y actualmente pues ya es una una startup, entonces, totalmente válido lo que dices Alexander. Muchas gracias. Sí, de nada, que. Bueno, siguiendo igual, eh pueden abrir el micrófono en cualquier momento.

El mito versus la realidad. El mito, que aquí nada más puse tres, que son como los que para mí son más importantes, pero en mitos puedo agrandar una lista de cientos. El mito. Gana el equipo con más líneas de código. Eso es falso. Al principio, eh hace unos dos, tres años, los hackatons sí se iban totalmente por quién tenía el mejor código, quién tenía mejor la quién tenía mejor una landing page, quién tenía la mejor diseño del UI UI, etcétera.

Pero la realidad es de que ahora gana el equipo que resuelve un problema y que lo haga bien. Porque de qué de qué vale tener, y eso es un pensamiento que tienen los jurados, entonces para que ustedes igual lo tengan como en ese contexto, de a a mí de qué me sirve tener la mejor aplicación del mundo que hace mara- que hace maravillas, si a las personas es si las personas están están buscando una aplicación para mover dinero nada más y mi página resuelve eh cosas de inteligencia artificial, es un ejemplo.

Entonces, esto se tiene que adaptar al contexto de donde ustedes están participando y del hackaton, entonces aquí ya se engloban dos partes importantes. El estudio del hackaton y el estudio de donde ustedes están, ¿no? Entonces, ahora ahorita igual abriendo como este paréntesis, es como de ah, okay, estoy participando en el hackaton de Lima, en donde principalmente es Arbitrum, entonces tengo que utilizar la tecnología, la blockchain y tengo que hacer contratos inteligentes en Arbitrum.

Esto cómo lo puedo pegar a lo voy a poner el ejemplo, no aquí en México, aquí en México, que en donde yo vivo hay un problema muy grande para comprar dólares. Entonces, ese es como justamente esta línea de de sucesión que se debe de llevar para igual aumentar las posibilidades de que su idea sea una idea ganadora. Recordamos, gana no gana el equipo con más líneas de código, gana el equipo que resuelve un problema y que lo resuelva bien.

Igual justamente con esta parte, en unas diapositivas más adelante vamos a ver algo muy importante sobre el pitch. Siguiendo con el siguiente mito, que es dice, hay que dormir cero horas. Creo que los que hayan participado en hackatons, creo que y que son hackatons cortos de tres, cuatro días, casi siempre cuando es un hackaton de tres, cuatro días es en donde menos a veces las personas duermen porque se quedan tan tan pegadas, tan de cierta manera de de cierta manera tan obsesionadas de decir, esto tiene que quedar, esto se tiene que hacer y todo todo todo tiene que quedar bien, ¿no?

Es una hackaton. Si fuera una aceleradora de de Silicon Valley, ahí sí es aceptable, pero es una hackaton. En la hackaton lo que se busca es resolver un problema, no darle una solución al 100%. Entonces, el dormir es muy necesario porque si una si ustedes se descuidan en este ámbito, cuando ustedes vayan a hacer el el demo, cuando vayan a hacer el pitch o si es que siguen programando, la verdad es que sí afecta, sí afecta en el rendimiento y sobre todo en cómo uno piensa a veces eh puede empezar uno bien, pero no duerme esta noche y se queda hasta la siguiente noche a la

madrugada y ya se queda de, no, es que esto no sale y le pide a la IA, la IA le da un resultado y luego usted ustedes revisan el el código y no saben qué es lo que está mal, no saben qué moverle, entonces es importante dormir. No no esto no es un requisito del hackatón el no dormir, entonces la dormir es es importante para tener muy claro lo que la idea, muy claro todo y que pues ustedes estén también de cierta manera relajados para todo lo que se tiene que afrontar.

Siguiendo con el siguiente que es Sí. Hola Ian, por ahí tenemos unas manos levantadas. Ah, okay, adelante eh Yas. Hola, buenas tardes. Ah, una pregunta. Ah, el para ganar los proyectos ah deben ser originales, ¿no? Y así no no a los productos que ya existen en mercado. Porque en otro hackatón que yo estaba ahí los gana el primer ganador, su proyecto ya estaba en así su proyecto ya estaba un producto que él estaba vendiendo en otro sitio. Entonces ¿cómo es?

Sí, bueno, eh ayer justamente en el kickoff se habló sobre eso de que sí se pueden traer proyectos, en este caso si son de otras blockchains pero pues sí tienen que ser lo suficientemente buenos y que te ocupen toda la tecnología de Ethereum, en este caso de Arbitrum. En este caso un ejemplo, si tú tienes eh un proyecto que sea web 2, que no sea sobre blockchain y lo quieres traer a la blockchain pues yo creo que igual ahí estaría de cierta manera válido. Pero si ya tienes un proyecto que esté en otra blockchain eh igual a ver si ahorita este Javi me me corrige por si estoy por si lo estoy diciendo mal.

Creo que se había comentado que sí se puede pero se tiene que traer a Arbitrum y pues de cierta manera el proyecto tiene que tener pues algo algo adicional que sí tenga tracción. Claro. Gracias, muchas gracias. Allí para complementar eh lo que se espera también en esta Hackathon es que si tienen un proyecto avanzado como se va a realizar sus repositorios, sus portafolios y archivos ver el avance sustancial, ¿no? Tal vez ustedes puedan documentar hasta, por ejemplo, ¿no? Una anterior Hackathon avanzaron hasta tal de su proyecto y en esta Hackathon qué han avanzado, entonces comentar ello

también nos sirve a nosotros para saber eh si realmente ha habido un trabajo detrás. Bien, igual está César. César Abel. ¿Qué tal? Buenas tardes. Eh mi consulta era con respecto a que, bueno, con mi equipo que vamos a postular a esta Hackathon no tenemos mucha experiencia en el tema de blockchain, de hecho algunos somos primerizos pero sí tenemos experiencia técnica en otros lenguajes y me había llamado la atención bastante lo que habían puesto de ejemplo de un equipo que ganó sin saber nada de blockchain.

Eh justamente nosotros hemos reservado una cita con un mentor a las 6 de la tarde. ¿Cómo nos sugeriría darles, bueno, darles un resumen al al al mentor para que nos dé una guía, ya que no no tenemos mucha experiencia en este tema? Okay, lo más importante cuando tú vas a hablar con con un mentor y de cierta manera es tu primer contacto con blockchain es primero tener bien definida tu Eh hay hay algo muy importante que se llama, se les voy a escribir por el por el chat que se llama One Pager. Eso es lo que hace One Pager o White Paper.

¿Qué es lo que qué qué qué significa el One Pager o el White Paper? Lo que hace es de que ustedes eh en una hoja, bueno, depende eso no no nomás es una hoja, es la extensión que ustedes quieran. Es escribir su proyecto con detalles de qué es lo que va a solucionar y lo que ustedes esperan de hacer de como entregables. Los eh los entregables, el un ejemplo, ¿no? Entregable número uno, el contrato inteligente, entregable número dos, el la presentación, el entregable número tres, el pitch, etcétera, ¿no?

Entonces, como recomendación mía, justamente hacer un un white paper one pager de su idea, donde desglosen lo que ustedes quieren lograr. Como igual, ¿no? Ustedes platiquen, platiquen con tu equipo, igual, ¿no? Decir, "No, pues es que yo me siento bien hasta llegar hasta un ejemplo, ¿no?" Hacer el proyecto, tener la idea, desplegar un contrato inteligente y que ese contrato inteligente, pues ya va a manejarlo la lógica de su proyecto, ¿no? Y sobre ese contrato inteligente ya van a hacer una una página web que va a funcionar lo demás, ¿no?

Entonces, eh mi consejo es de que lo hables con tu equipo, hagan este white paper en donde los todo tu equipo eh pues esté de acuerdo, porque igual muchas veces si llegan a tener diferencias adentro del equipo, puede haber ahí cierta fricción en la idea, ¿no? De que uno diga, "No, es que para mí esto yo no quiero esto." O luego hay alguna chico o chica que diga, "No, es que yo tampoco quiero esto." Entonces, quedar de acuerdo en lo en la idea, hacer el white paper y cuando vayan con el mentor, ir presentárselo y pues obviamente que el mentor eh los guíe un poco en cómo cómo hacerlo.

Igual, al final, un poco más al final de de la presentación, igual les voy a compartir unos recursos para que ustedes lo los puedan leer. Vale, muchas gracias. Sí, no hay de qué. Bueno, hay una pregunta en el chat que dice, "Buenas tardes, si yo postulé solo, ¿aún puedo traer a mi equipo o cómo puedo hacer?" Ay, no sé si Javi nos pueda responder esa pregunta. Claro, eh recuerda que tienen hasta el 3 de agosto todavía con el formulario activo para que ustedes puedan postular.

Recuerda que la postulación es individual. Y en la plataforma hay una sección para eh inscribir a su equipo, ¿no? Entonces, sí, aún va a estar activo. De hecho, a ver cómo les les explico la mecánica. Hasta el 3 ustedes se pueden inscribir, ¿no? De manera individual. Y va tienen hasta el 7 de agosto, que es un día antes del del Demo Day, para que ustedes puedan afinar, poner nombres, descripciones y demás que ustedes van a encontrar en cuanto se habilite durante la semana.

Entonces, sí, no hay problema allí. Eh en caso, por ejemplo, pueda haber algún caso de complicación con la plataforma, ahí sí por el Discord nos comunican. Listo gracias. Vale. Eh ¿se sigue viendo la presentación? Sí. Vale. Siguiendo con con esto, eh nos quedamos en el mito. La idea más compleja gana. Eso es de cierta manera falso, debido a que de primera instancia, cuando están participando en un

hackathon, lo que se busca es tener una idea que solucione un problema y que lo haga bien, como lo vimos en el primer aspecto, que justamente como que dice, ¿no? La idea más fácil de explicar en 2 minutos gana. Entonces, pues justamente esto es lo que se tiene que tener en mente y justamente como como aquí hay un comentario de de Puki que dice, "Ese equipo programó 30 horas seguidas y no pudo ni prender la demo." Y esto es muy real, demasiado demasiado real que lo he visto, me pasó también a mí, le pasó a compañeros y amigos que han participado en diferentes hackatons que hicieron obras monumentales de back-end,

de programación en back-end, pero ya después para hacer un front-end y hacer la demo no pudieron. Y simplemente porque no pudieron su demo se vio degradada y pues no tuvieron como esas probabilidad de tener más éxito solamente porque le dieron full enfoque a a hacer más complejo el back-end, hacer más complejo algún algún ámbito del proyecto y pues de ahí ya no ya no es se se logró lo demás. Entonces, esto es muy importante.

Y también aquí viene, creo que justamente ya todos aquí pues eh sabemos que caen casi en todos los hackatons se utiliza eh pues GitHub, Git o GitHub para hacer el el historial de del proyecto, para poderlo desplegar eh después en en Vercel o alguna otra plataforma para tenerlo en en línea. Y pues aquí igual es muy importante. A veces ya se sabe si se ganó o se perdió antes del primer commit que se haga al repositorio.

Suena un poco agresivo esto, pero muchas veces tiene mucho que ver. Primero, lo que comentaba antes, el equipo. Antes de empezar a desarrollar y todo, lo el equipo. Ustedes ya tienen a su equipo, ya ya están ahí. Ya bueno, al menos aquí puse, ¿no? Arma tu equipo por roles, no por amistad. Aquí voy a contar una anécdota y no es como que para que lo hagan, para que ahorita le esté diciendo, no, no se junten con sus amigos para hacer un hackathon, sino de que les voy a contar una anécdota que sucedió en una hackathon que que en la que yo participé.

Un equipo de chicos de aproximadamente unos 18, 19 años, estaban en la universidad, que seguían estudiando, que ganaron un primer lugar y el premio fue de $5,000. El premio fue demasiado grande para y pues es un buen dinero para chicos universitarios, ¿no? Y eso que el equipo nada más era de tres. ¿Qué fue lo que sucedió? Que justamente muchas veces en las hackathons cuando cuando se llega a ganar, es llega a ese punto un poco incómodo de de hablar, ¿okay?

Y el premio, ahora, ¿qué es lo que va a hacer? Casi siempre lo que sucede es que las personas no se pueden poner de acuerdo cómo van a a quedar con con el premio, ¿no? Entonces, esto es muy importante, porque desde antes de empezar a hacer el el proyecto, lo que tienen que hacer, pues, es armar un buen equipo y hablarlo todo. Si son sus amigos, hablarlo muy bien de cómo eh si llegan a ganar, eh cómo se van a repartir el premio, si son créditos, etcétera, ¿no? Entonces, eso es una parte muy importante para poder trabajar bien en todo el transcurso y ya tener como eso pactado desde antes.

Porque ya si puedes puede hacer mucha fricción esto entre los compañeros de de equipo. Entonces, igual es muy muy muy importante tener demasiada comunicación con con su equipo y pues charlar todo esto que es como el comento, ¿no? A veces sí es un poco incómodo, pero es necesario eh charlarlo. Como siguiente punto, igual tenemos lo del track. Entonces, eh leer bien qué es lo que ejemplo ahorita en este hackathon, leer muy bien qué es lo que de cierta manera se pide, los entregables.

Y pues eh afinar eh dirigir el proyecto para tener todos todos esos entregables. Teniendo eso, pues ya cumplen, vamos a decirlo, que el 100% de lo que se necesita para poder evaluarlos. Y pues ya la demás evaluación pues va a ser sobre la narrativa del proyecto y lo que esté desarrollado. También, justamente como ya lo había comentado, los jueces. Investigar de cierta manera quiénes son los jueces, si pueden charlar con ellos, así nada más casualmente. Y pues igual, ¿no? Ver si si han premiado en algunos otros hackathons antes, qué han dicho antes, y pues vamos a decir que debe ser un poco de esto.

Justamente esto les ayuda en dos cosas. En que tengan visibilidad. La visibilidad con los jueces es muy importante, porque muchas veces si ustedes igual con los mentores, si los mentores y los jueces ven que ustedes preguntan, que ustedes ya subieron una historia a a Instagram, tienen su su entrevista a a un usuario, a una persona, aunque sea su hermano, su hermana, eso de verdad que les aumenta muchísimo las probabilidades de tener un éxito en un proyecto y en una idea.

Porque los jueces ven y dicen, "Okay, estos chicos están progresando, estos chicos ya desarrollaron, estos chicos ya tienen una historia de usuario." Entonces, pues todo eso es muy importante y es muy bueno para todo su su trayecto. Y lo último, pero no menos importante, es el setup. Qué iguales van a utilizar, qué entorno de desarrollo van a utilizar, qué SDKs si van a utilizar APIs, ver si son de paga, si son gratuitas, etcétera. Igual justamente pues eh esto es importante de ver para que cuando empiecen a programar ya sea si se hace en coding manual que pues ya muchos ahorita nos apalancamos de la inteligencia artificial para poder

entregar un buen proyecto. Igual saber darle instrucciones a la inteligencia artificial para que lo haga bien. Que justamente quiero hacer un un paréntesis, eso lo justamente el lunes igual voy a hacer workshop a las 12 sobre IA y blockchain donde voy a hablar un poco de integrar la IA al proyecto y utilizar la IA para el proyecto. Entonces eh igual por si les interesa igual va a ser el el workshop el día lunes. Entonces un poco de todo lo que hemos hablado, vamos a decir que reuniendo la parte de de la idea, de la del lo que han desarrollado y del

etcétera. Aquí es todo es muy importante el scope pequeño que funciona. O problema real más solución demostrable en 2 minutos yo creo que ese sería estas seis palabras es lo que a ustedes más les puede ayudar, lo pueden anotar en alguna libretita o en algo y un ejemplo hoy en la noche adelantan al proyecto y dicen okay, es un problema real porque la gente lo necesita, porque cierta industria lo necesita, etcétera y nosotros lo podemos solucionar en el hackathon y lo podemos eh demostrar en 2 minutos.

Depende de cuánto tiempo sea el pitch, 2, 3 minutos aproximadamente. Entonces esta esta estas líneas es muy importante para que ustedes lo lo recuerden y mediante y mediante vayan avanzando en el hackaton lo puedan volver a leer y decir y y validar si ustedes mismos, okay, seguimos con un problema real y la solución que la estamos haciendo y que también la vamos poder hacer en 2 minutos, 3 minutos, depende del del tiempo de la demostración.

Siguiendo también aquí es por es chistoso porque llega a suceder demasiado demasiado demasiado demasiado y esto es una de la parte que igual involucro como toda esta parte que les había comentado de que duerman bien, de que tengan buena comunicación con su equipo porque pues yo creo, ¿no? Las personas que están en una hackaton pues llega a haber demasiados entusiastas que se obsesionan de cierta manera, ¿no? Con entregar algo y pues hacerlo de de lo la mejor manera posible, ¿no?

Y aquí dice se gana en las últimas 6 horas, pero también se pierde en las primeras 6. Y esto ¿por qué? También puede ser al revés, que diga eh se pierde en las últimas 6 horas y se gana en las primeras 6. Porque puede que ustedes en las primeras 6 horas del hackaton, en el primer día, en el primer día y medio tienen su equipo, están trabajando de buena manera y están adelantando una idea al proyecto, ya tienen su primer smart contract desplegado pero ¿qué pasa? Las últimas 6 horas dicen, "No, es que esto ya no funcionó" y empiezan a decir, "Ah, sí, ahorita lo arreglo" pero cuando tratan de

arreglarlo se rompe más de lo que se está arreglando. Eso llega a pasar demasiado. Igual cuando se va a hacer la entrega hay muchas personas que siguen subiendo eh código, que sigan haciendo cómics al GitHub una dos una, dos o tres horas antes. Mi recomendación es de que ya no le hagan cómics, de que ya no vamos a decirlo, que su su deadline de su proyecto para ustedes va a ser unas tres horas antes de la deadline original para que en esas tres horas ya no se modifique nada.

Si ne si si último cómic en GitHub fue el que ya funcionó bien, el que no se rompió ni nada así déjenlo, de verdad ya ya no le muevan ya no le metan aunque sea una una corrección en no sé, en alguna letra, porque simplemente por hacer alguna modificación se les puede romper y de ahí pues empieza la el nerviosismo de ay, lo voy a arreglar, es que ya no se arregla y tenemos que grabar el el pitch, es que ya lo tenemos que presentar y ahora qué va a va a suceder.

Entonces justamente esto es eh importante que lo tengan en en mente de que su proyecto quede ya funcional aproximadamente unas, bueno, ese es mi consejo, igual puede ser una hora antes una, dos, tres horas, yo creo que sería lo indispensable antes del deadline original para que ustedes eh vean que está totalmente bien, para que puedan grabar su demo bien y que no se rompa nada. Que ve bueno, aquí dice los checkpoints, revisar los avances cada pocas que esté pulido que se bloqueen justamente como estaba eh comentando, que bloqueen un tiempo fijo solamente para la demo. Que un ejemplo, no dicen, okay, dos horas antes de de la deadline original ya está el

proyecto hecho, okay, entonces le vamos a dedicar una hora completa al al demo y pues sale mejor, ¿no? Porque ya no tienen el eh esa presión de es que el proyecto no funciona, es que le falló esto, con el proyecto funcional, hacen su demo tranquilitos y pues sale hasta mejor la demo. La energía, justamente, es muy importante también. Cuida el el estado del equipo, eh su interacción con los demás. No solamente cuiden el código, cuiden a su equipo, cuiden cómo están interactuando, que no haya problemas de por medio, como lo estaba mencionando, de que desde un principio como equipo tengan bien definidos, pues, todas las cosas que se tengan que ver

para que no haya fricciones y, pues, para que estén lo lo más tranquilo posible, porque igual el añadirle presión, nervios a todo eso y de repente que se enojen, pues, sí añade otras capas que que pueden afectar al rendimiento del equipo y, pues, a los entregables que se tengan que hacer. Y bueno, pues, ya es es un poco lo mismo, la comunicación, que sea clara y directa bajo presión, que si están en que si están a una hora y falla fa- falta algo y así, pues, que tengan una comunicación clara, porque todo el equipo pueda hacerlo bien y, pues, eh evitar los mayores problemas o

los mayores pro- problemas posibles que que puedan haber en en su equipo. Bien. Ya para para ir terminando con esto, igual esto en el pitch, nadie premia lo que no lograste explicar. Esto igual con lo que ya habíamos charlado un poco antes. Mmm, el demo es muy muy importante y el pitch lo es. Siguiendo con todo lo que hemos eh charlado, vamos a decir lo que todo esto ya se compacta aquí en el pitch.

Tene- tienen un problema real que ustedes lo solucionaron en blockchain, en Arbitrum, y ahora lo tienen que explicar lo mejor posible, que su explicación lo pueda entender un un chavo de 16 años, lo puede entender su mamá, lo puede entender su papá o hasta su abuelito. Con esto que todos lo puedan entender está bien. Obviamente en el pitch tengan que agregar un poco de de lenguaje un poco técnico, más porque a veces los jueces se lo piden de Leo les hacen una pregunta de oye cómo hiciste este este método en tu contrato, cuántos métodos tiene en

tiene tu contrato, etcétera, ¿no? Entonces eh posiblemente sí lo tengan que agregar, pero que sea entendible. Si ustedes llegan a un pitch y dicen, "Ah, es que nosotros desplegamos un contrato con un método de recurrencia y utilizamos el el la licencia del MIT 2.0, lo hicimos en Solidity pragma 0.81, etcétera." Puede que sí tengan más fricción porque están explicando lo que hay detrás pero no están explicando la solución deben de explicar la solución, no como hace rato puse el ejemplo de la veterinaria de voy a poner ese mismo ejemplo, ¿no? Voy

a hacer mi pitch y el pitch el que voy a hacer el siguiente está mal, ¿por qué? Porque voy a pitchearlo así. "No, es que mi veterinario utilizamos eh utilizamos soluciones salinas de de X químico para que los perros al operarlos y utilizamos bisturís de plata y etcétera, ¿no?" Y si tú se le le dices algo así al cliente es como de "Okay, ¿a poco le vas a meter plata a mi perro?" En vez de decir, "No, pues nosotros utilizamos eh las herramientas patentadas, la última tecnología en las soluciones para etc, etc, ¿no? No sé si me di a entender.

Entonces, esto es eh importante. Igual como que dice, problema, solución, demo en vivo y el impacto que tenga. Igual, un consejo que yo para podría dar es que le añadan emoción a la a la demo, que no solamente lean y y hablen, sino que de verdad ustedes eh le añadan como esa emoción a la demo, al pitch, para que también le transmitan un poco de sentimiento, un poco de esa emoción, un poco de lo que ustedes están hablando a las demás personas, porque pues esto también le añade añade un poco más de como de de vivez, de sentimiento y la verdad también es se siente bien.

Y pues justamente aquí en la parte del pitch, anticipar un poco las preguntas obvias de los jueces, no sé, un poco de las preguntas que muchas veces hacen es ¿cuántos contratos tienen? Y si ya se ponen muy muy técnicos en lo en tema de los contratos inteligentes que muchas veces preguntan, les van a preguntar en qué versión lo hicieron de solidity, cuántos métodos tiene el contrato, si si el contrato tiene recurrencia, etcétera. Y igual esta parte, ¿no? 2 minutos de demo ensayada y ah, es esto es muy importante, que las slides no tengan mucho texto.

Ahorita eh pues ya terminamos la parte de la presentación, voy a presentar eh una cosa rápida. Aquí si tienen eh preguntas, igual me pueden contactar por Telegram. Si tienen eh alguna duda, algo que tenga que ver, estoy totalmente abierto a estoy a su disposición de de ayudarles. Voy a dejar de compartir tantito esto para compartirles esto lo que sí se ve el modelo link canvas muchas veces no, bueno, posiblemente me

estoy adelantando un poco, hay un workshop justamente de un pitch de para un pitch próximamente, pero al menos de desde miles les digo que si pueden utilicen el modelo link canvas para hacer su presentación y su pitch el modelo link canvas pues utiliza justamente esta parte de problemas, solución, métricas clave proposición eh única de valor, la ventaja espacial la ventaja especial los canales y etcétera, ya posiblemente la parte de como financiera, como aquí dice de flujo de ingresos o estructura de costes posiblemente sí sea bueno que lo añadan, pero si su proyecto no lo amerita y

muchas veces esto está un poco más de extra como añadirle costos y así, depende, ¿no? Del proyecto, si están hablando de algún proyecto financiero, que utilice dinero, posiblemente sí sea bueno añadirlo pero si están hablando un proyecto más de desarrollo o así, posiblemente no no sea tanto entonces ahí igual aquí les dejo un poco como esta parte del el modelo link canvas que esto yo se lo recomiendo ya es una recomendación personal y pues obviamente pues esperen al al workshop del del pitch, obviamente yo creo que ahí les van a dar más eh información sobre más información importante sobre esto

bueno, no sé si hasta el momento eh tienen alguna duda, comentario Creo que no. Bien, ya para ir finalizando les preparé un repositorio de de GitHub. Aquí vienen hm varias cositas importantes. Ejemplo aquí.

Tenemos eh glosarios, tenemos como un cómo hacer un roadmap de 72 horas, tenemos justamente la parte como de antes de un hackathon, tener como su setup eh hecho, que si van a utilizar algún alguna algún agente de inteligencia artificial, Cloud GPT Gemini eh saber eh qué herramientas existen. Igual que lo de inteligencia artificial no voy a adentrar tanto ahorita porque lo vamos a ver en la siguiente sesión. Y pues aquí vienen demasiados, demasiados recursos, IA para las hackathons, construcción de MVP, demo y pitch, recursos, etcétera. Aquí también puse unas plantillas

del one pager y del del pitch. Igual justamente lo que le estaba platicando a al chico que preguntó de que va a tener una reunión con con un mentor ahorita, pues se pueden meter, déjenles comparto la liga. Se pueden meter aquí, pueden copiar el la parte del one pager. El link del repo ya se los pasé por aquí del del chat, igual lo voy a mandar por Discord.

Lo subo rápido al Discord para que se quede ahí. Ah, no tengo permisos. Bueno, ahí Javi yo creo lo lo subirá. Sí, ahí lo subiremos en el canal de recursos.

Eh, igual por ahí me pasas tu tu usuario para para habilitarlo. Vale. Y pues aquí vienen demasiadas cosas, entonces para el One Pager de los chicos igual aquí viene. Y igual este este repositorio está hecho para que no lo tengan que leer. Este repositorio está hecho para que ustedes se lo compartan a su agente de IA preferida, sea hace Cloud, sea hace Codex, sea hace Antigravity, y ustedes le pidan un ejemplo, ¿no? Eh, realízame el One Pager y mediante los recursos del del repositorio, y él ya va a tomar las plantillas de de este repositorio y ya lo va a hacer eh

ya ya no van a ahorrar tokens en que para que la su agente ya no busque la plantilla, busque la información, ya todo va a estar aquí. Entonces para que para que lo utilicen y pues espero les les sea de de demasiada utilidad Igual les repito, el lunes igual a las a la 1 a la 1 de la tarde, hora Perú, em, va a haber eh vas a dar otro workshop de IA más Blockchain.

Va a ser justamente un poco más largo ese workshop. Va a ser sobre cómo implementar IA a tu proyecto y cómo utilizar la IA para potenciarlo. Entonces para que estén ahí y creo que ahora sí de momento sería todo de mi parte, no sé si si tengan alguna duda antes de Ah, bueno, aquí hay un mensaje. Dice, ¿qué recomiendas hacer si mi equipo a mitad de hackathon no responde o si veo que no tienen la motivación con la idea o proyecto? Es muy una pregunta muy buena.

¿Qué te recomiendo? Yo creo que depende del índole de tu proyecto, si es muy grande o pequeño, lo que tendrías que hacer es si de plano ya no te darles un rango, ¿no? Un ejemplo eh hoy te contestaron, pero mañana ya no te contestaron, eh tres horas y pues tú tienes ustedes tienen que seguir trabajando, ¿no? Yo creo que le de que les des como una como un un un periodo de tiempo para decir, bueno, si me contestan, podemos seguir eh trabajando, pero si ya no, pues ya tienes que cambiar un poco las las cosas del proyecto, ¿no? Entonces, mi recomendación es que les des justamente como esta ventana de tiempo para ver si

te contestan y si de plano ya pierden la motivación o así, la verdad no puede ser un poco bueno, que los trates de de motivar, pero también si de plano no, que tú te lo avientes eh como que tú puedas eh pues sí, que lo hagas tú solo, que trates de de entregarle el MVP, el el proyecto mínimo viable y pues decir, ¿no? Que pues tu equipo sucedió esto y así. Muchas veces igual los los jueces lo lo entienden y pues igual le toman toman justamente

como esta parte en cuenta, ¿no? Porque muchas veces igual posiblemente ahorita haya unos, eh por ejemplo, 60 equipos, pero en todo el transcurso desertan unos 10 y ya al final nada más se entregan 30 equipos, entonces eso igual ténganlo en cuenta, es algo que igual les daría como recomendación ver como cuántos más, cuántos equipos más hay, cuántos participantes para saber como qué es qué es lo que se espera, ¿no? En el hackathon, cuántos proyectos se van a entregar. Pero sí, sobre todo si tu equipo de cierta manera como que pierde la motivación y así, sería como tratar de hablar con ellos para ver si si de verdad van a seguir participando o no, y si de plano ya no, pues tratar de hacerlo tú solo tratando de priorizar la demo. Si en tu

proyecto eh ya no ya no hay tiempo, tu equipo ya se desertó deja el código y enfócate en dar un buen pitch. Un buen un buen pitch, un buen pitch puede hacer maravillas, entonces esa sería mi recomendación para ti, Andre. ¿A qué hora será? Va a ser a la 1 de de la tarde, hora Perú. Bueno, es que, perdón, es que digo hora Perú porque para mí ahorita acá en México es la la 1 de la tarde apenas, para allá son las 2 si es que no mal me parece.

Y aquí dice Lil ¿Qué es lo que no se debería usar para la elaboración de los proyectos? ¿Qué no se debería de el de usar? Creo que es un poco ambigua la pregunta, creo que no es como que haya algo prohibido no es como que no creo que no es como que haya algo prohibido de un dentro de un hackathon para para elaborar un proyecto, creo que ahorita pues obviamente la la inteligencia artificial, como les comentaba, es una herramienta que todos ahorita utilizamos más en los hackathons pero pues que sí que se tiene que saber utilizar

de buena manera para que no entregue malos resultados. Bueno, creo que ya no hay más preguntas. Bien.

Bueno, la verdad, muchas gracias, grandes tips la realidad. Has mencionado varias cosas sobre que están en las bases, pero también que vamos a dar de recomendaciones para el demo de que se va a tener. Entonces, eh y justamente este recurso es bastante útil, ¿no? Eh que ya te pueda ahorrar tokens ya es un recurso demasiado valioso. Una vez, gracias por nuevamente esta oportunidad de estar con nosotros, nos vienes apoyando desde el año pasado y también nos veremos en Igualmente a las demás personas, gracias por su asistencia, cualquier eh aporte, soporte o algún comentario, por el Discord lo estamos atendiendo.

Eh se han habilitado dos canales ahora, que es el de recursos, donde vamos a subir el video y el GitHub para tenerlo fijado. Y también la parte del canal de voz, ¿no? Por si algún mentor se une, no bastantemente por ahí pueden revisar y unirse, ¿no? Hacerle la consulta directa si es que no tiene algún no es este plan o paso en su en su calendar, pues pueden optar por el canal de voz. Igual, cualquier comentario de disponibilidad eh nos lo estamos comentando por el Discord.

Ahora, queremos comentarles algo que justamente estamos por publicarlo en el chat. Eh acá en Lima sobre todo, para aquellos que estén acá, vamos a habilitar una hacker house en el centro de Lima donde van a poder asistir, van a poder tener un descuento para poder consumir en el lugar y la dirección estamos enviando por el Discord o por las redes sociales. Entonces, cualquier consulta la estamos atendiendo por ahí. Muchas gracias a todos por asistir, gracias IA y nos estamos viendo en la próxima sesión.

Sí, muchas gracias igual a ustedes a la asistencia igual eh de cual cualquier duda que tengan estoy activo en Discord como Clavel, entonces ahí estaremos. Muchas gracias Javi.