Agencia de DevRel en Latinoamérica: qué hace, cuándo contratar una y qué preguntar (2026)

Una agencia de DevRel, o agencia de developer relations, en Latinoamérica hace el trabajo que una empresa no puede hacer desde el extranjero: talleres y office hours en español o portugués, presencia en comunidades y universidades de las ciudades donde están sus desarrolladores, contenido y documentación locales, eventos, y el circuito de retroalimentación de vuelta a producto. Las alternativas son un developer advocate interno para la región y una empresa de programas para desarrolladores que ejecuta un programa acotado con un reporte al final. Cuál contratar depende de cuatro señales, y las preguntas que conviene hacer antes de firmar son las mismas para las tres opciones. Esta guía cubre qué entrega en realidad la agencia, en qué se diferencian las tres opciones, cuándo cada una es la decisión correcta en México y el resto de la región, y qué dejar por escrito.

Puntos clave

• Una agencia de DevRel vende personas bajo un retainer: advocates, redactores, community managers y apoyo en eventos. Una empresa de programas para desarrolladores vende un programa con inicio, fin y un reporte de quién construyó qué. Un advocate interno es dueño de la relación con el producto. La mayoría de las empresas que entran a Latinoamérica necesitan la última opción más una de las dos primeras.
• Cuatro señales indican que es momento de contratar ayuda externa: desarrolladores de la región que ya usan el producto sin nadie de la empresa en la sala, un equipo de DevRel de una a tres personas cubriendo todas las regiones desde el extranjero, un producto que necesita sesiones y documentación en español, y una fecha (un lanzamiento, una entrada a mercado, un plan de contratación) a la que una contratación interna no llegaría.
• El entregable que separa un programa de un retainer es el reporte: desarrolladores únicos que completaron una primera build, proyectos presentados en showcase, equipos que siguen construyendo 30 días después, instituciones con nombre y las preguntas que hicieron los desarrolladores. Las impresiones y la asistencia quedan como contexto.
• Mobil3 no publica lista de precios. Una cotización desglosa el equipo en terreno, las sedes, los créditos, el tiempo de los mentores, los viajes entre ciudades y el reporte, y las horas de ingeniería de la propia empresa son el costo que nunca aparece en la factura.

Qué hace en realidad una agencia de DevRel

Developer relations es el trabajo de lograr que los desarrolladores usen un producto y de llevar lo que dicen de vuelta a quienes lo construyen. Dentro de una empresa, el trabajo se divide en advocacy, contenido, comunidad, eventos y developer experience. Una agencia vende algunas o todas esas partes como servicio, normalmente bajo un retainer mensual con un equipo asignado, y el catálogo de la mayoría de los sitios de agencias se lee igual: contenido para desarrolladores y redacción técnica, documentación, gestión de comunidad, eventos y hackathons, developer advocacy, lanzamientos y retroalimentación hacia producto. La unidad de DevRel de Software Guru en México, por ejemplo, enumera organización de hackathons, developer enablement, gestión de relaciones con la comunidad, organización de retos y gestión de eventos, y dice que lleva más de 14 años trabajando con desarrolladores de software (Software Guru DevRel, consultado en noviembre de 2026, descripción del proveedor).

En Latinoamérica el catálogo es más corto en la práctica, porque la empresa casi siempre ya tiene el contenido y la plataforma de comunidad. Lo que le falta es presencia. Los desarrolladores que podrían adoptar el producto están en el Instituto Politécnico Nacional en Ciudad de México, en la Universidad de Guadalajara, en un meetup en Monterrey o en un grupo de builders en Bogotá, y el equipo de DevRel está en San Francisco, Berlín o Singapur. El trabajo de la agencia pasa a ser la mitad en terreno de developer relations: sesiones prácticas donde los desarrolladores construyen con el producto, office hours mientras los proyectos siguen vivos, activaciones en campus y comunidades, showcases y hackathons locales, documentación y código de ejemplo en español, y un relato escrito de qué se construyó y qué estorbó en el camino.

Esa división importa al leer una propuesta. Un retainer que lista contenido, redes, comunidad y "eventos" entrega un calendario. Un programa que lista talleres en tres ciudades, office hours con tus ingenieros, un showcase y un reporte entrega builders. La adopción de desarrolladores es un programa, no un canal explica por qué existe la segunda lista; DevRel vs developer marketing: el tercer trabajo que falta explica por qué ni un equipo de DevRel en el extranjero ni un presupuesto de developer marketing lo cubren.

Tres formas de comprar developer relations en Latinoamérica

El mismo trabajo se compra de tres formas. Cada una tiene una unidad de trabajo distinta, un responsable distinto y un entregable distinto, y la mayoría de las empresas que lo hacen bien combinan dos de ellas.

Opción	Unidad de trabajo	Qué obtienes	Dónde falla
Developer advocate interno para la región	Una persona, contratada por un año o más	Conocimiento del producto, conversaciones sobre el roadmap, una cara que los desarrolladores reconocen, la relación con ingeniería	Contratar toma meses; una persona no puede cubrir tres ciudades, una docena de universidades y el calendario de contenido; el puesto se convierte en viajes
Agencia de DevRel	Un equipo bajo retainer mensual	Advocates, redactores, community managers y apoyo en eventos, que se amplía o reduce por mes	El retainer mide actividad (publicaciones, eventos, miembros) salvo que el contrato diga otra cosa; la profundidad local depende de a quién tenga la agencia en cada ciudad
Empresa de programas para desarrolladores	Un programa con inicio, fin y reporte	Talleres, créditos, office hours, showcases y un conteo de quién construyó qué, en ciudades e instituciones con nombre, ejecutado por un equipo que ya está ahí	Acotado al programa; no escribe tu documentación ni administra tu Discord; funciona mejor cuando alguien interno es dueño de la relación

Mobil3 es del tercer tipo. Se define como empresa de programas para desarrolladores, y la página de agencia de programas para desarrolladores explica qué significa eso en palabras del comprador: las empresas que contratarían una agencia de programas para desarrolladores o una agencia de DevRel contratan a Mobil3 para lograr que desarrolladores en México usen su producto, mediante talleres, créditos, kits de inicio, office hours y showcases de proyectos en universidades y comunidades de Ciudad de México, Guadalajara y Monterrey, con la adopción reportada al final. La empresa conserva su propio equipo de DevRel. Mobil3 le da operadores locales, salas y audiencias. Servicios de adopción de desarrolladores en México enumera cada componente de ese programa y qué determina su costo.

Cuándo contratar una: cuatro señales

La pregunta no es si DevRel importa en la región. El Octoverse de GitHub contó más de 1.9 millones de desarrolladores en México, con un crecimiento cercano al 21% anual (GitHub Octoverse 2024), y su edición 2025 registró 3.2 millones de desarrolladores nuevos en Latinoamérica en un año, nombrando a Brasil, México y Colombia (GitHub Octoverse 2025, octubre de 2025). La edición 2026 reportó que solo Brasil sumó 3.28 millones de desarrolladores en GitHub en el año, el tercer país que más creció (GitHub Octoverse 2026, octubre de 2026). La pregunta es si la empresa puede llegar a ellos con lo que tiene. Cuatro señales indican que no puede, y cada una apunta a un tipo de ayuda distinto.

Los desarrolladores de la región ya usan el producto, y nadie de la empresa los ha conocido. Aparecen registros desde México o Brasil en el dashboard, existe un hilo en un foro en español que nadie del equipo puede leer, y la primera charla local sobre el producto la dio alguien a quien la empresa no conoce. Es la señal más fuerte, porque la demanda existe y lo único que falta es presencia. Una empresa de programas puede arrancar después de un discovery de unas dos semanas; un retainer de agencia o una contratación interna suelen tardar más en producir esa misma primera sesión.

El equipo de DevRel son una a tres personas cubriendo todas las regiones desde el extranjero. Un equipo de ese tamaño no puede sostener office hours en tres zonas horarias y un calendario de campus en otro país. El equipo interno debería conservar la relación con el producto y delegar la operación regional a alguien que ya está ahí. En este caso un retainer o un programa funcionan como multiplicador, no como reemplazo.

El producto necesita sesiones y documentación en español o portugués. Muchos desarrolladores en Latinoamérica leen documentación en inglés. En la encuesta de desarrolladores de Solidity de 2024, el 88% de quienes respondieron dijo que le parecía bien leer la documentación en inglés y el 12% prefería su idioma nativo, en una encuesta que se aplicó solo en inglés (Solidity Developer Survey 2024 results, abril de 2025). Una encuesta solo en inglés deja fuera a los desarrolladores que habrían respondido en español, y esos son justo los que alcanza un taller en español. Si la empresa no tiene a nadie que pueda enseñar el producto en español, la primera sesión se convierte en un ejercicio de traducción. Pregunta a cualquier proveedor quién dirige la sala y en qué idioma, y si el kit de inicio se entrega en ambos.

Existe una fecha a la que una contratación interna no llegaría. Un lanzamiento en la región, una entrada a mercado, un hackathon que la empresa quiere patrocinar bien, un plan de contratación que necesita candidatos que ya construyeron con el producto. Contratar un developer advocate para México toma meses desde la decisión hasta la primera visita a un campus, entre la búsqueda, el periodo de aviso y la curva de arranque; un marketplace de contratación de Estados Unidos estima que una contratación interna para un rol de developer marketing toma de tres a seis meses (MarketerHire, Developer Marketing Agency: How to Pick One, julio de 2026, una estimación del proveedor sin metodología publicada). Un programa puede empezar con un discovery de unas dos semanas y agendar la primera sesión en cuanto se confirme la fecha del campus o de la comunidad. Cuando la fecha es fija, el programa compra tiempo para la contratación, y la persona contratada hereda las instituciones que el programa conoció.

Si ninguna de las cuatro se cumple, contrata internamente primero. Un advocate que es dueño de la relación con el producto, habla el idioma y vive en la región sacará más provecho de cualquier agencia o programa posterior que una empresa que subcontrata toda la función. Cómo entrar al mercado fintech de México cubre la versión de esta decisión que toma una fintech antes de tener a alguien en el país.

Qué cambia cuando la región es México

Tres cosas hacen que México sea distinto de ejecutar el mismo trabajo en Estados Unidos o Europa, y las tres afectan lo que una empresa debería pedirle a un proveedor.

La sala se recluta a través de las universidades. Las comunidades de campus suelen ser el primer lugar donde los desarrolladores en México tocan el stack de una empresa, y un proveedor sin relaciones con los docentes recluta desde cero en cada sesión. Mobil3 trabaja con más de 15 universidades en sus programas, incluidos el Instituto Politécnico Nacional en Ciudad de México, la Universidad de Guadalajara en Jalisco y la Universidad del Norte en Monterrey, con más de 12 activaciones universitarias y más de 250 participantes únicos en el conjunto de sus programas. El trabajo con universidades sigue el calendario académico, así que las fechas y los campus se confirman durante el diseño, no después; trabajar con universidades en México explica cómo ese calendario moldea un programa.

Tres ciudades, no una. Ciudad de México, Guadalajara y Monterrey tienen cada una sus propias universidades, comunidades y meetups. Un programa en una ciudad no tiene línea de viajes; un programa en las tres tiene vuelos, hoteles y días de traslado para el equipo del proveedor y para los ingenieros que se suman a las sesiones. Pregunta si el programa viaja o si es una ciudad con participación remota, y pregunta quién está en terreno en cada una.

Las comunidades de desarrolladores llenan el hueco que deja el calendario de campus. Los meetups y los grupos de builders llegan a desarrolladores en activo que ya pasaron por la universidad, y funcionan todo el año. Hacktoberfest México 2026 se realizó en Ciudad de México el 27 y 28 de octubre durante Mexico Tech Week, organizado por Mobil3 con Major League Hacking dentro del Hacktoberfest oficial, con ElevenLabs, n8n, Lovable, MojoAuth y Firecrawl como patrocinadores de retos (Hacktoberfest México 2026). Las sesiones en eventos así llegan a una sala que el calendario de campus nunca ve. La mayoría de los programas mezclan ambos, con los mismos créditos, kit de inicio y office hours detrás de cada sesión.

Nueve preguntas antes de firmar

Las respuestas a estas nueve preguntas separan un programa de un retainer, sea quien sea el proveedor y se llame como se llame. Pídelas por escrito.

1. ¿Quién dirige la sesión práctica en la sala, y puede resolver un problema de entorno en el momento? Pide los nombres y las ciudades donde viven. Un líder regional con itinerario de vuelos no es lo mismo que un operador que estuvo en ese mismo campus el mes pasado.
2. ¿Qué universidades y comunidades ya están en la sala, con nombre? Una lista por reclutar más adelante es un plan. Una lista de instituciones con las que el proveedor trabajó en sus dos últimos programas es evidencia.
3. ¿En qué idioma se da la sesión, y el kit de inicio se entrega en español? Incluidos el código de ejemplo, la documentación y las office hours.
4. ¿Qué contiene el reporte final, y cuándo llega? Desarrolladores únicos que completaron una build, proyectos presentados en showcase, instituciones con nombre, el estado a 30 días de cada equipo y las preguntas que hicieron los desarrolladores. Pon la fecha de entrega en el contrato.
5. ¿Cómo se cuentan los desarrolladores únicos? Registros, asistencia y builders únicos son tres números distintos. Pide el método de conteo, y el número de personas que completaron una primera build, no el número de personas que estuvieron sentadas en la sala.
6. ¿Qué pasa entre sesiones? Las office hours con los ingenieros de la empresa mientras los proyectos siguen vivos son el componente que las empresas dejan fuera del alcance con más frecuencia, y el que mantiene los proyectos en movimiento. Pregunta quién las conduce, con qué frecuencia y durante cuánto tiempo después del último taller.
7. ¿De quién es lo que se construye? Lo que construyen los desarrolladores normalmente les pertenece a ellos, salvo que todos hayan acordado otra cosa por escrito antes del programa. Pide que los términos se publiquen junto con el reto.
8. ¿Cómo se comparten los datos de los participantes? Qué campos, bajo qué consentimiento, por cuánto tiempo. La lista de participantes es el entregable que más merece una regla por escrito.
9. ¿Cuál es la versión más pequeña de esto? Un solo día de taller en un campus, con office hours y un showcase, es una prueba real de un proveedor. Un retainer que solo funciona a doce meses no lo es.

Un proveedor que responde las nueve por escrito está vendiendo un programa.

Qué medir, y qué dejar fuera del titular

La mayoría de los proyectos de hackathon se detienen en el demo day. Un estudio revisado por pares sobre proyectos de hackathon encontró que cerca del 65% no muestra trabajo técnico posterior al evento, y solo el 3.55% sigue activo cinco meses después (Nolte, Chounta y Herbsleb, Proceedings of the ACM on Human-Computer Interaction, CSCW, octubre de 2020, consultado en noviembre de 2026). Un retainer que termina cada mes en un evento repite esa curva doce veces al año. Los cuatro números que pertenecen al titular de un reporte son los mismos que reporta un programa de adopción para desarrolladores: desarrolladores únicos que completaron una build, proyectos presentados en showcase, equipos que siguen construyendo 30 días después y las instituciones con nombre de donde salieron. Asistencia, miembros de la comunidad, impresiones y publicaciones quedan como contexto. Métricas de éxito de un hackathon explica cada número, y la prueba para cualquier otra métrica es la misma: ¿el número se vería igual si nadie hubiera construido nada con tu producto? Si la respuesta es sí, es contexto.

Interno, agencia o programa: una regla de decisión corta

Contrata internamente primero si no tienes a nadie que sea dueño de developer relations para la región y ninguna fecha fuerza la decisión. Suma una agencia de DevRel cuando el equipo interno necesite más manos para contenido, comunidad y un calendario de eventos constante en varios países. Suma una empresa de programas para desarrolladores cuando necesites builders en ciudades e instituciones con nombre, con un reporte, para una fecha. Muchas empresas que entran a México hacen las dos últimas en secuencia: primero un programa, para conocer las universidades y comunidades y dejar las primeras builds en el registro, y después una contratación o un retainer que hereda esas relaciones. La página de programas lista los formatos que ejecuta Mobil3, desde un solo día de taller hasta una serie de un semestre, y la página para empresas lista lo que los acompaña: hackathons, eventos y apoyo de go-to-market para empresas que llegan sin oficina.

Si tu producto necesita builders en México, envía una solicitud por escrito a través de la página de contacto con el producto, los desarrolladores a los que quieres llegar y tu fecha. Mobil3 responde en dos días hábiles, y todo programa empieza con un discovery de unas dos semanas.