Arenga Studio

Contexto

En 2024 llevaba dos años trabajando en Librodepases cuando me di cuenta de algo incómodo: la mayoría de startups con las que hablaba en Buenos Aires no podían acceder a diseño de producto real. Podían contratar agencias de branding o freelancers de UI, pero nadie que se sentara con ellos a entender qué construían y por qué, y que además pudiera implementarlo.

Con Martín —mi co-fundador, que viene del lado de desarrollo— vimos el mismo gap desde lados distintos. Él había trabajado con equipos que tenían diseños preciosos que nadie podía buildear. Yo había trabajado con equipos que buildeaban sin diseñar. La solución obvia era juntarlo.

El nombre viene de la charla técnica antes de un partido. Esa concentración de intención antes de la acción. Nos gustó como metáfora: pensamos en serio, después ejecutamos rápido. Sin presentaciones de 40 slides antes de escribir una línea de código o trazar un wireframe.

El problema

El mercado de servicios de diseño para startups early-stage en Argentina tenía dos extremos: agencias de branding que entregaban un manual de identidad y desaparecían, o desarrolladores que construían “lo que el cliente pedía” sin cuestionar si eso resolvía algo.

El resultado era siempre el mismo: productos que se veían bien en presentaciones y eran difíciles de usar en producción, o productos funcionales que nadie podía defender frente a un inversor o a un usuario nuevo. El problema no era falta de talento — era falta de alguien que trabajara los dos lados a la vez.

Approach

Decidimos muy temprano que Arenga no iba a hacer “estrategia y después te presentamos el Figma”. O trabajamos desde adentro —con acceso al producto real, a los usuarios, al código— o no trabajamos.

Nuestro criterio de aceptación tiene tres preguntas: ¿tenemos acceso directo al equipo que construye? ¿El cliente puede darnos feedback real de usuario en las primeras dos semanas? ¿Hay algo concreto que shipped a los 45 días? Si las tres son sí, arrancamos. Perdimos algunos proyectos con ese filtro. Los que entraron fueron mejores.

Decisiones clave

Decisión 1 — Solo proyectos, sin retainers de horas

El modelo de retainer por horas es cómodo para el estudio pero genera incentivos equivocados: facturar horas en lugar de resolver problemas. Decidimos cobrar por proyecto con entregables definidos y revisión cada dos semanas.

Lo que perdimos: previsibilidad de ingresos mes a mes. Lo que ganamos: clientes que saben exactamente qué van a recibir y cuándo, y la disciplina interna de definir bien el scope antes de arrancar.

Decisión 2 — Máximo tres proyectos en paralelo

Con dos personas en el equipo core, más de tres proyectos simultáneos significa perder el hilo de cada uno. Pasamos meses rechazando trabajo para sostener esa regla. Todavía duele cuando hay proyectos interesantes que no podemos tomar. La alternativa —hacerlos mal— duele más.

Decisión 3 — Posicionamiento como “Product Design + Build”, no “UX/UI”

“UX/UI” es el término que usa la gente que contrataría un freelancer junior. “Product Design + Build” define una expectativa distinta: vamos a cuestionar qué se construye antes de diseñar cómo se ve.

Costó un trimestre de ventas con prospectos incorrectos hasta que los correctos empezaron a llegar solos, la mayoría por referidos de los primeros clientes.

Trabajo representativo

Spark Club — Plataforma de membresías para un social club tech en CABA. Fuimos desde research con socios hasta producción en once semanas. El flujo crítico de onboarding se simplificó drásticamente y la tasa de completación mejoró de forma significativa.

EEVA Studios — Rediseño del sistema de booking para un estudio de fotografía y video. El cliente llegó con un formulario de Google que requería seguimiento manual por email. Salimos con un sistema propio que integra disponibilidad en tiempo real: la gran mayoría de los bookings se cierran sin intervención manual.

Impacto

En 18 meses: 8 productos entregados, clientes recurrentes y varios referidos directos entre el portfolio. Operamos sin inversión externa desde el día uno.

La métrica que más nos importa: tasa de adopción del producto a los 30 días de entrega. Si el usuario final no usa lo que construimos, algo estuvimos haciendo mal — y eso no lo arregla ningún contrato bien redactado.