- Cap rate neto: mide el activo, rinde sin importar cómo se paga.
- ROI a 1 año: mide al inversor, acá sí pesa cómo se financia.
- vs. el barrio: percentil, no promedio; dónde cae en su mercado.
La capa de análisis de inversión que le falta a cada ficha de propiedad: de mostrar números a ayudar a decidir
La mayoría de los buscadores inmobiliarios tratan a una propiedad como un lugar para vivir: ambientes, metros, barrio, precio. El inversor le hace otra pregunta al mismo aviso: ¿esto es un buen negocio, y para qué tipo de inversor? Modo Inversor es una capa que ideé y diseñé de punta a punta para responder esa pregunta adentro del producto, en lugar de mandar al usuario a una planilla aparte. La tesis de todo el caso cabe en una línea: mostrar números no es lo mismo que ayudar a decidir.
Sobre una propiedad de ejemplo (Belgrano, USD 180.000, 30% de entrada) el motor devuelve:
Cap rate neto
2,98%
ROI a 1 año (contado)
+5,18%
Leverage ratio
3,33×
Roomix resuelve buscar y descubrir mejor que nadie; lo que falta es responder si una propiedad es un buen negocio. Ese es el hueco.
Roomix es el buscador inmobiliario con IA más grande de Argentina: analiza más de 500.000 publicaciones (departamentos, casas, terrenos, locales) en venta y alquiler, de inmobiliarias y de dueños directos. Su sello es la búsqueda en lenguaje natural ("escribí lo que buscás con tus palabras"), más colecciones de favoritos y alertas por WhatsApp. Es gratis, AI-first y cubre todo el país. Encima ya tiene una capa de herramientas: simulador de créditos hipotecarios, calculadoras de ajuste de alquiler (IPC/ICL), tasador online, detector de estafas. Es un producto que abraza la idea de "herramientas que te ayudan a decidir".
Y justo ahí vi el hueco. Con todo eso, ninguna herramienta responde la pregunta del que compra para invertir: "¿esta propiedad es un buen negocio?". El tasador te dice cuánto vale; el simulador hipotecario, cuánto pagás de cuota. Pero nadie conecta alquiler, precio, apreciación y financiación en una sola respuesta. Ese usuario termina, igual que antes, en una planilla de Excel.
De ahí salió la idea del Modo Inversor: una capa sobre cualquier ficha de propiedad que responde "¿esto es una buena inversión, y para qué tipo de inversor?". Encaja con el ADN de Roomix (AI-first, orientado a herramientas) y llena un vacío real.
Aprendí el dominio financiero de cero y lo destilé en una spec que se volvió la fuente de verdad del motor.
Para diseñar esto no me alcanzaba con entender a Roomix. Tuve que aprender el dominio financiero-inmobiliario desde cero: cap rate bruto y neto, NOI, ROI contado vs. apalancado, el efecto real del crédito sobre el retorno, y todo el contexto argentino (UVA, bimonetarismo, ajuste por inflación, el riesgo de que la cuota real en dólares se dispare).
Destilé esa investigación en una especificación de dominio (domain.md): las fórmulas, los inputs
del usuario, los defaults macro y los escenarios. Esa spec se volvió la fuente de verdad del motor: todo
lo que el prototipo calcula sale de ahí. No inventé números para que la demo se viera linda, los derivé
del dominio que investigué.
Diseñar sobre un dominio que no dominás arranca con humildad: primero entenderlo bien, recién después decidir cómo presentarlo. La mitad del trabajo fue research; la otra mitad, traducir ese rigor en una experiencia que un no-analista entienda sin sentirse tonto. Y no salió a la primera: cada decisión de abajo es una iteración.
El giro central: de una calculadora que tira números a una respuesta que los interpreta. Interpretar no es recomendar, es orientar.
Con el dominio entendido, diseñé una primera versión. Mostraba los tres escenarios en paralelo, unos nueve números, una comparación contra el barrio, y cerraba con un implícito "decidí vos". Tenía todo el rigor del motor, y por eso mismo no servía. La probé y se sentía mal.
El diagnóstico de raíz: construía una calculadora para un usuario que vino a tomar una decisión y no sabe interpretar los números. "Mostramos datos, no recomendaciones" se estaba usando como excusa para no interpretar.
El usuario de Roomix no es analista financiero. Tirarle cap rate neto más ROI contado y apalancado por tres escenarios, y arriba "decidí vos", le descarga toda la carga cognitiva encima. Lo paraliza: ve números, no sabe si invertir o no.
La decisión central del proyecto fue pasar de planilla a respuesta interpretada. La UI lidera con una respuesta en castellano ("2,98% de cap rate neto; para Belgrano es bajo: zona de apreciación, no de renta"), las capas avanzadas son opt-in, y todo cierra en una acción. Interpretar no es recomendar: es explicar qué significa el número y para quién tiene sentido, sin decir "comprá".
Antes de las pantallas, los principios. Cada decisión pasó por estos filtros:
No diseño pantallas lindas: muevo una palanca de negocio. Pienso cada decisión como una apuesta sobre el funnel: captar al usuario que invierte, que confíe, y que llegue a la acción.
Seis decisiones de diseño, cada una un trade-off explícito.
El deep-dive era un informe lineal larguísimo para leer de arriba a abajo: sin un resumen arriba de todo, con el mismo dato (cap rate) apareciendo en tres formatos visuales distintos, y la card roja del ROI negativo como lo más pesado de la pantalla, justo el número que el copy decía que "no es un veredicto".
Lo convertí en un tablero: un scorecard de KPIs arriba (cap rate, ROI, vs. barrio, apreciación),
reactivo, como el resumen de cinco segundos que tiene todo producto del rubro; un componente Stat
único que codifica cada número igual en toda la pantalla; una re-secuencia (resumen, tu input,
escenarios, barrio, crédito, veredicto, acción); y la financiación colapsada en un acordeón, que saca
el negativo del centro de gravedad y abre a demanda. La pantalla se acortó casi a la mitad.
El copy también lidera con la conclusión. Antes, subtítulos descriptivos ("mismo inmueble, distintos supuestos macro"). Después, conclusiones que orientan:
Mata la parálisis. El usuario que probó el original dijo, textual, "veo solo números, estoy colapsado, no sé si invertir o no". La conclusión-líder y el "para quién" le dan un lugar donde pararse. Y de paso maté la jerga que excluye al no-analista: "neto de vacancia" pasó a "descontando meses vacíos", "NOI" a "resultado neto", "(no-cash)" a "(no es plata en mano)". Los términos que vienen con su explicación al lado (cap rate, apalancamiento) se quedan, cada uno con su popover.
La comparación era "esta propiedad vs. mediana": dos barras. La convertí en un histograma de la distribución de cap rates del barrio, con tu propiedad marcada y el percentil como insight-líder ("Percentil 28: 7 de cada 10 deptos rinden más que este").
Es la diferencia entre un portal y un producto de inversión. "Dos barras" te dice un dato; "dónde caés en la distribución" te da el contexto que define la decisión.
Calcular el retorno con un solo número da una falsa sensación de precisión que el contexto argentino, con volatilidad macro alta, no soporta. Elegí tres escenarios (peor caso, caso base, mejor caso) porque son los puntos mínimos para definir un rango con centro. Subir a cinco o siete agrega categorías intermedias difíciles de comunicar ("moderadamente conservador" no le dice nada a nadie).
Cuando hice reactivo el selector apareció una pregunta de modelo: ¿el escenario cambia el rendimiento de alquiler (cap rate) o solo la apreciación? La decisión: el escenario es una apuesta sobre la apreciación, no sobre el yield de hoy.
El cap rate (que es NOI sobre precio, puro presente) aparece igual en los tres escenarios. Es conceptualmente correcto y evita un error peligroso: que el usuario crea que "ser optimista" mejora lo que la propiedad rinde hoy. El cap rate es tu realidad del año 1; el escenario es tu apuesta sobre el futuro.
La decisión que más me importó. Tres movimientos, todos del lado del usuario:
El cap rate evalúa el activo sin importar cómo se paga. El ROI evalúa al inversor, donde sí importa cómo se paga (deuda, hipoteca, capital propio). El crédito convierte una renta floja en una apuesta a apreciación: el ROI apalancado se mueve respecto del contado en un factor igual al leverage ratio (valor del activo sobre capital propio). Con 30% de entrada, ese factor es 3,33×, y amplifica tanto la ganancia como la pérdida:
| Escenario de apreciación | ROI al contado (180k) | ROI con crédito (54k) |
|---|---|---|
| 2,2% (moderado) | +5,18% | -6,16% |
| 5% (agresivo) | +7,98% | +3,17% |
La pregunta que el producto responde tiene dos partes: "¿esto es buena inversión, y para qué tipo de inversor?". La segunda la resolví sobre dos ejes, no con un selector de personas.
El movimiento obvio habría sido un selector Conservador / Moderado / Agresivo de perfiles. No lo construí, a propósito: esos tres no son tipos de inversor, son apuestas de apreciación macro (un pronóstico), no estrategias. Tratarlos como perfiles es un error conceptual. Por eso, en vez de fabricar personas, hago el eje real imposible de ignorar a través del copy y la estructura.
Perfiles explícitos: lo que descarté
Se ven más "producto", configurables. Pero fabrican una taxonomía (Conservador / Moderado / Agresivo como personas) que el modelo no sostiene, y sobre-diseñan una v1.
Distinción emergente: lo que elegí
Mantiene el eje financiero real al frente, no inventa categorías, y es honesta sobre lo que los datos soportan hoy. El costo: la orientación vive en el copy y la estructura, así que generalizarla a cualquier propiedad es trabajo de v2.
Lo que no segmenté, a propósito: alquiler tradicional vs. temporario tipo Airbnb, la segmentación que más falta. La dejé afuera porque depende de ocupación, estacionalidad y tarifa por noche (datos que no tengo y que el dominio no modela), y porque meterla a medias habría sido peor que no meterla. Es el candidato número uno a v2: en CABA, un monoambiente en Palermo puede rendir 2-3× en temporario contra el tradicional.
El prototipo no es estático: computa. Mover el supuesto de alquiler propaga el recálculo por cap rate, escenarios, distribución y financiación. Construí un bloque "motor en vivo" que corre las fórmulas del dominio usando expresiones y condicionales nativos de Figma (suma, resta, multiplicación, división, más if/else), con la barra y el mensaje recalculando en tiempo real.
El criterio acá fue no fingir capacidades: descubrí los límites reales de la "programación" de Figma y diseñé
alrededor de ellos. La propiedad characters solo acepta string (no float) y las expresiones no formatean
ni concatenan, así que los gráficos van por width (continuo, computado) y los números y mensajes por
strings y umbrales. Las condicionales son como máximo dos bloques (if más else), y los tres estados se
resuelven con "default más dos overrides". Es raro en un portfolio de diseño ver un prototipo que calcula
en lugar de simular estados pre-horneados.
Y las gráficas, elegidas con criterio. Exploré cuatro: un fan chart (proyección de valor a 10 años con banda de incertidumbre), un área apilada (equity en el tiempo), un donut (composición del cap rate) y gauges radiales (KPIs). Apliqué el criterio "una gráfica se gana su lugar solo si muestra lo que un número no puede", e integré dos, descarté dos:
Un lenguaje visual restringido parece producto; un muestrario parece demo. Descartar bien es diseñar.
El cap rate en USD no depende solo del alquiler: depende de si la devaluación le gana al ajuste. Ese es el corazón del modelo.
Acá está el detalle que diferencia un modelo serio para Argentina de una calculadora genérica. La propiedad se publica en USD pero el alquiler se cobra en ARS. Esa disociación obliga a dos supuestos que no existen en mercados estables como Madrid o Miami: qué tipo de cambio uso para convertir el ingreso, y cómo proyecto esa conversión durante la tenencia.
La consecuencia es contraintuitiva: el retorno en USD no depende solo del ingreso neto de hoy, sino de si, a lo largo de la tenencia, la devaluación del peso le gana o no al ajuste del alquiler. La fórmula central del motor:
U₁ / U₀ = (1 + i) / (1 + d)
Donde i es la tasa de ajuste del alquiler (uso el ICL como proxy) y d la devaluación del peso vs. USD.
Si i > d, el alquiler en USD crece; si i < d, cae. Es el concepto de
paridad de poder adquisitivo
aplicado a un activo único. Por eso el cap rate es un solo número de hoy (el ingreso neto actual
convertido a USD sobre el precio actual), pero el retorno a futuro no: bajo cada escenario, la misma
propiedad rinde distinto según si la devaluación le gana o no al ajuste. Eso es exactamente lo que el
motor proyecta en el ROI, no en el cap rate.
Los defaults (vacancia, inflación, devaluación, apreciación por barrio) están construidos por triangulación de fuentes públicas: Zonaprop, INDEC, BCRA y La Nación. No hay vacancia medida oficialmente en CABA, así que el rango lo armé cruzando datos de oferta que sí existen, y lo marco como supuesto del modelo, no como dato. El marco regulatorio de fondo es el DNU 70/2023, que liberó la elección de índice y moneda de ajuste.
Un usuario probó la pantalla y me dijo "no sé qué leer". Tenía razón, y el fix fue mostrar solo la respuesta por defecto y esconder el resto detrás de un opt-in.
Acá viene la parte incómoda. Apliqué el reencuadre (scorecard arriba, financiación colapsada) y se sentía bien. Pero le mostré la pantalla de análisis a un usuario y me dijo, textual: "hay demasiada info, no sé qué leer." Tenía razón, y dolía: el proyecto nació para matar exactamente eso (la planilla que te paraliza), y la pantalla se había vuelto a llenar.
El diagnóstico: había hecho disclosure progresivo a medias. Puse un scorecard arriba, pero dejé todo el informe debajo (motor, distribución, proyección a 10 años, financiación), apilado con el mismo peso visual. El veredicto quedaba al fondo, después de scrollear un muro. Era "respuesta más planilla", no "respuesta".
El fix fue invertir la lógica. Por defecto, la pantalla muestra solo la respuesta: el veredicto en una línea, el scorecard (cuatro KPIs), el "te conviene si… / no si…", y la acción. Todo el resto (incluido el selector de escenario) colapsa detrás de un "ver el análisis detallado", interactivo y opt-in. La profundidad sigue ahí, a un click, pero no te la tira en la cara. La pantalla por defecto se redujo a poco más de un tercio y entra sin scroll.
Lo que me llevo: disclosure progresivo hecho a medias sigue siendo sobrecarga. Y el mejor feedback es el que te marca que recommitiste el pecado que saliste a matar. Lo importante fue escucharlo y matar densidad sin ego, colapsando lo que yo mismo había construido.
Stat consistente, y un
lenguaje de gráficas restringido.Ser honesto sobre los huecos es parte del trabajo. Para una v1 está bien; para producción, no:
El prototipo de Figma simulaba el cálculo (variables más expresiones). Este capítulo es lo que pasa cuando el prototipo deja de simular y empieza a calcular de verdad: un motor en TypeScript que toma una propiedad y devuelve sus métricas de inversión. Lógica pura, sin UI: hoy es solo el motor y sus tests.
El motor es TypeScript estricto, sin dependencias de runtime, framework-agnostic (después lo importa la UI; hoy no hay UI). Lo construí con TDD (red, green, refactor), y el detalle que lo vuelve demostrable en vez de "confiá en mí" es esta equivalencia:
Seis decisiones de implementación, todas ancladas a la spec del dominio.
domain.md sección 3.3 define los inputs y outputs; el motor los implementa tal cual (EngineInput a
EngineOutput, con los tres escenarios en paralelo). Cada constante lleva su @see domain.md sección X:
no hay números mágicos, hay trazabilidad al research.
calcNetCapRate (alquiler de hoy) y calcProjectedNetCapRate (proyectado bajo macro) son dos funciones
distintas. La tesis yield-vs-retorno del diseño ahora la enforzan los tipos y los tests, no un comentario.
El ROI usa el cap rate proyectado porque es un retorno del año; mezclar "yield de hoy" con "apreciación
del año" sería usar dos relojes distintos. Acá fue donde el test me marcó que me había equivocado.
projectRent, calcOperatingBreakdown, computeFinancing: cada cuenta vive una sola vez. El cap rate,
el NOI y el ROI componen esas primitivas en lugar de repetirlas. Lo aprendí refactorizando: mi primera
versión "des-dividía" el cap rate para recuperar el NOI; lo di vuelta para que el NOI sea el ladrillo y el
cap rate derive de él, no al revés.
DEFAULT_SCENARIOS codifica la tabla de la sección 2.5: lo que cambia entre Conservador, Moderado y
Agresivo es vacancia más ajuste más devaluación más apreciación. El cap rate del activo no "mejora" por
ser optimista. Y la vacancia vive en el escenario, no en la propiedad (es un supuesto macro, no un
atributo del activo): un test que corría los tres escenarios con vacancias distintas me forzó a moverla
ahí. El test maneja el diseño.
Conceptos financieros universales en inglés (priceUSD, capRateNet); términos argentinos sin traducir
(expensasMonthlyUSD, ablQuarterlyUSD, ICL, UVA). Cap rate como ratio decimal (0.0293): el ×100 vive
en la UI, el motor no sabe de formato. La frontera de unidades es explícita.
El ROI apalancado puede dar negativo (-6,16% en el caso E) y el motor lo devuelve tal cual: el flujo de caja negativo es real ("ponés plata de tu bolsillo cada mes"). El motor no maquilla y no dicta: devuelve datos estructurados por escenario, no un veredicto, la misma postura que el diseño.
analyzeProperty(input) es la única puerta de entrada.Próximo capítulo: conectar el motor a la interfaz, que analyzeProperty alimente el scorecard, los
escenarios y la financiación reales, y cerrar la v2 (proyección a 10 años, distribución del barrio, UVA
denominado en UVAs).
El caso tiene dos piezas. En diseño: prototipo navegable en Figma con un design system propio (Foundations y librería de componentes, con los estados tipados por las variables del motor). En código: el motor de cálculo ya está construido como una librería de TypeScript de lógica pura (cap rate, ROI, financiación y escenarios), cubierta con tests en Vitest y sin UI. La interfaz en Next.js y la persistencia en PostgreSQL son el siguiente capítulo.
Publico esto en parte para que me lo discutan. Aprendí el dominio financiero de cero para este proyecto, así que si trabajás en real estate, en finanzas, en producto o en diseño y ves algo que no cierra, me gustaría saberlo.
Sobre el diseño y el producto (qué sacarías, agregarías o cambiarías):
Sobre el análisis (lo más técnico):
Si algo de esto te hizo pensar, o pensás distinto, escribime.
En resumen
Tomé Roomix (el mayor buscador inmobiliario con IA de Argentina) y le diseñé la capa que le falta al que compra para invertir: una que no solo calcula cap rate, ROI y escenarios, sino que los interpreta y orienta la decisión sin dictarla. Mi primera versión era una calculadora que tiraba nueve números y decía "decidí vos"; la reencuadré en una respuesta que lidera con la conclusión, calcula en vivo y es honesta sobre el riesgo. Después la llevé de prototipo en Figma a un motor en TypeScript con tests. Research de dominio, diseño que interpreta y rigor de implementación, en una sola pieza.
