Building Arenga Studio

Contexto

Arenga empezó antes de tener nombre.

En abril/mayo de 2024 empecé a co-pensar el proyecto junto a Nico, diseñador de branding, mientras ya veníamos trabajando en proyectos con Delfín de Push N Pull como partner técnico y de desarrollo. Al principio no era una agencia formal. Era una forma de trabajar que empezaba a repetirse: ordenar ideas de negocio, darles identidad, convertirlas en producto y acompañar la ejecución con desarrollo cerca desde el inicio.

Unos meses después se sumó Jaz, con quien venía trabajando en Libro de Pases y compartía una forma muy similar de desarmar productos complejos, bajar flujos y tomar decisiones de UX con criterio de negocio. Con su entrada, el proyecto terminó de tomar forma: definimos nombre, marca, concepto visual y una propuesta más clara.

Ahí empezó realmente Arenga.

El nombre viene de la charla técnica antes de un partido. Ese momento donde el equipo se junta, baja una idea, ordena la intención y sale a ejecutar. Nos gustó como metáfora porque representaba bastante bien lo que queríamos construir: pensar en serio, pero sin quedarnos eternamente en la estrategia. Convertir conversación en dirección. Dirección en sistema. Sistema en producto.

El problema

El mercado de servicios para startups y equipos early-stage suele moverse entre dos extremos.

Por un lado, agencias que trabajan muy bien marca, identidad o comunicación, pero se alejan cuando llega el momento de convertir eso en producto. Por otro lado, equipos de desarrollo que construyen rápido, pero muchas veces sin cuestionar demasiado el problema, la experiencia o la lógica de uso detrás de lo que se está construyendo.

En el medio quedan muchas startups con una necesidad concreta: alguien que pueda ordenar una idea todavía borrosa, convertirla en alcance, diseñar una experiencia clara, darle una identidad sólida y acompañar la ejecución hasta que algo real pueda salir a producción.

El problema no era solo conseguir clientes. Era construir una forma de trabajo capaz de sostener eso sin transformarnos en una agencia pesada, lenta o difícil de operar.

Necesitábamos definir qué era Arenga, qué tipo de proyectos aceptaba, cómo se armaban los equipos, cómo se estimaban los alcances, cómo se documentaban las decisiones y cómo se colaboraba con desarrollo sin que diseño y build fueran dos etapas desconectadas.

Approach

Dos principios guiaron la construcción del estudio.

Diseñar la agencia como un producto. No empezamos preguntando “qué servicios ofrecemos”, sino qué problema queríamos resolver, para quién y con qué tipo de experiencia de trabajo. Arenga tenía que tener una propuesta clara hacia afuera, pero también un sistema operativo claro hacia adentro.

Pensar antes, ejecutar cerca del producto. No queríamos vender diseño como una capa visual aislada. El valor estaba en trabajar desde el problema, definir el alcance, ordenar flujos, prototipar, documentar y colaborar con desarrollo para que las ideas no quedaran atrapadas en Figma.

La web, la marca, los procesos, los templates, las propuestas comerciales y los entregables fueron distintas expresiones de la misma pregunta: cómo hacemos que un equipo chico pueda trabajar con criterio de producto, buena ejecución visual y capacidad real de delivery.

Decisiones clave

Diseñar la agencia como un sistema, no como una suma de servicios

Al principio era fácil caer en una lista amplia de cosas que podíamos hacer: branding, UX/UI, diseño web, MVPs, auditorías, handoff, no-code, estrategia, workshops, contenidos, sistemas de diseño.

El problema de esa lista es que explicaba capacidades, pero no explicaba una propuesta.

La decisión fue ordenar Arenga como un sistema de trabajo alrededor de momentos concretos del cliente: cuando necesita lanzar una marca y una web, cuando necesita convertir una idea en MVP, cuando necesita rediseñar o mejorar un producto existente, o cuando necesita un acompañamiento más continuo de diseño y producto.

Esto ayudó a mover la conversación de “qué pantallas necesitás” a “qué estás intentando construir y qué necesitás validar primero”.

Lo que descartamos: vender Arenga como una agencia generalista de diseño. Podíamos tomar proyectos muy distintos, pero si todo entraba en la misma bolsa, era más difícil vender, estimar y operar.

Construir un equipo extendido, no una estructura pesada

Arenga no nació con la idea de tener todos los perfiles in-house desde el día uno. Eso hubiera sido caro, rígido y poco realista para la etapa en la que estábamos.

La decisión fue trabajar como un equipo core con una red de partners confiables. Nico desde branding e identidad, Jaz desde producto y UX, yo conectando estrategia, producto, UI, gestión y delivery, y Delfín / Push N Pull como partner técnico para desarrollo, implementación y criterio de build.

Ese modelo nos permitió adaptar el equipo a cada proyecto sin sobredimensionar la estructura. Para algunos proyectos necesitábamos más peso de branding. Para otros, más arquitectura de producto. Para otros, desarrollo y QA desde etapas tempranas.

Lo que descartamos: intentar parecer una agencia grande antes de tener la operación para sostenerlo. Preferimos construir una red chica, senior y flexible antes que vender capacidad que no podíamos garantizar.

Pasar de proyectos custom a paquetes más claros

Durante los primeros proyectos, gran parte del trabajo comercial era explicar desde cero qué hacíamos, cómo lo hacíamos y dónde empezaba o terminaba cada alcance.

Eso generaba mucha fricción: propuestas largas, estimaciones difíciles de comparar y conversaciones donde el cliente no siempre entendía qué estaba comprando.

La decisión fue empezar a ordenar la oferta en líneas más claras: Brand + Web, Lanzamiento de Producto MVP, proyectos personalizables y, como evolución, un modelo de Product/Design Partner para acompañamientos mensuales.

No se trataba de encerrar todos los proyectos en paquetes rígidos, sino de crear puntos de entrada más fáciles de entender. Un buen sistema comercial no elimina la personalización, pero sí reduce la ambigüedad.

Lo que descartamos: cotizar cada proyecto como si fuera completamente único. Muchos proyectos tienen diferencias reales, pero también patrones repetibles. Identificar esos patrones fue clave para vender mejor y operar con más claridad.

Documentar para reducir fricción

Una de las decisiones más importantes no fue visual, fue operativa: convertir procesos internos en documentos reutilizables.

Creamos y fuimos iterando templates de briefing, propuestas, estimaciones, roadmap, handoff, gestión de revisiones y definición de entregables. La documentación no era burocracia. Era una forma de evitar conversaciones repetidas, ordenar expectativas y hacer que el equipo pudiera avanzar con menos dependencia de memoria o contexto informal.

Esto también nos ayudó a trabajar mejor con partners técnicos. Cuando diseño, desarrollo y cliente comparten una misma definición de alcance, los proyectos se vuelven menos frágiles.

Lo que descartamos: operar únicamente con conversaciones sueltas, audios y acuerdos implícitos. Eso puede funcionar en proyectos chicos, pero no escala. Si una decisión importante no queda escrita, tarde o temprano vuelve como malentendido.

Posicionarnos como Product Design Partner, no solo UX/UI

“UX/UI” describe una parte del trabajo, pero no alcanza para explicar el valor que queríamos ofrecer.

Arenga entra antes de la interfaz: en la definición del problema, la arquitectura, los flujos, la priorización, la experiencia, el sistema visual, el prototipo, el handoff y la conversación con desarrollo.

La decisión fue posicionarnos más cerca de producto + diseño + ejecución que de diseño visual aislado. Eso también implicó aceptar que no todos los leads eran buenos leads. Algunos buscaban solo “pantallas lindas”. Otros necesitaban realmente ordenar qué estaban construyendo.

Lo que descartamos: competir solo por ejecución UI. Ese mercado existe, pero no era donde Arenga podía aportar más valor. Nuestro diferencial estaba en conectar criterio de producto, identidad visual y capacidad de implementación.

La web como consecuencia del sistema

La web de Arenga no fue el centro del proyecto, pero sí una consecuencia importante.

No la pensamos como una landing para “mostrar trabajos”, sino como una capa visible del sistema que veníamos construyendo: qué hacemos, cómo trabajamos, para quién, con qué tipo de procesos y con qué resultados.

El desafío fue traducir una operación todavía en evolución en una narrativa clara. Mostrar proyectos como SparkClub, Garantear, Banndo o Beachwalk no solo como piezas visuales, sino como ejemplos de una forma de trabajo: ordenar complejidad, diseñar sistemas, colaborar con desarrollo y llegar a entregables accionables.

Lo que descartamos: una web puramente estética o demasiado aspiracional. La marca tenía que sentirse moderna y sólida, pero la propuesta necesitaba ser concreta. Si el sitio no ayudaba a entender cómo trabajamos, no servía.

Solución

Arenga terminó tomando forma como un estudio de diseño y producto con una estructura liviana, un equipo core claro y una red de partners técnicos para llevar proyectos desde estrategia hasta implementación.

La solución no fue una sola pieza, sino un sistema operativo compuesto por varias capas:

• una propuesta de valor más clara;
• líneas de servicio más fáciles de vender y estimar;
• procesos internos para discovery, arquitectura, diseño, handoff y QA;
• templates comerciales y operativos;
• una forma de colaboración con partners técnicos;
• un portfolio de casos que muestra distintos tipos de problemas;
• y una web que traduce todo eso hacia afuera.

Los proyectos representativos ayudaron a validar ese modelo desde ángulos distintos.

SparkClub nos permitió trabajar un MVP de producto con IA, tres tipos de usuario y un prototipo para inversión.

Garantear consolidó el trabajo sobre producto operativo, estados, portal de usuario y comunicaciones transaccionales.

Banndo fue un caso de traducción de marca a producto, rediseñando una app y ordenando su experiencia para una plataforma en crecimiento.

Beachwalk Resort llevó el enfoque a una web orientada a confianza, percepción y conversión para un negocio turístico.

Cada proyecto fue sumando una pieza al sistema: mejores preguntas de discovery, mejores propuestas, mejores handoffs, mejores formas de colaborar con desarrollo y más claridad sobre qué tipo de estudio queríamos construir.

Impacto

En su primer año y medio, Arenga trabajó con startups, plataformas digitales, productos en etapa temprana y sitios web en distintas industrias, construyendo un portfolio que combina MVPs, rediseños, branding, producto y desarrollo junto a partners técnicos.

Más importante que la cantidad de proyectos fue la repetición de un patrón: clientes que llegaban por referidos, proyectos que abrían nuevas oportunidades y procesos internos que se volvían reutilizables para el siguiente trabajo.

El estudio pasó de ser una colaboración informal entre perfiles complementarios a una estructura con nombre, marca, procesos, servicios definidos y una forma propia de operar.

Para mí, el mayor impacto fue interno: Arenga nos obligó a diseñar no solo productos para clientes, sino también la forma en la que queríamos trabajar como equipo.