Tasar una propiedad en Argentina es uno de esos procesos que nadie cuestiona porque siempre fue así: llamás a una inmobiliaria, coordinás una visita, esperás unos días y recibís un número que —seamos honestos— muchas veces sale más de la intuición del tasador que de datos concretos. Del otro lado, el dueño que quiere una segunda opinión abre los portales, mira a cuánto publican los vecinos y asume que eso es el valor de mercado. Spoiler: no lo es.

Con ese diagnóstico arrancamos a construir el tasador online de AgonProp: un producto donde cargás la dirección, las características y las fotos de tu propiedad, y en minutos recibís un informe profesional en PDF con un rango de valor, un nivel de confianza y un análisis de comparables reales de tu zona. Este post es el caso de estudio técnico: qué construimos, qué decisiones tomamos y dónde estuvieron los problemas interesantes.

Qué hace el producto (y qué no)

El flujo completo, visto desde el usuario, es un wizard de cuatro pasos: dirección, características de la propiedad, fotos y pago. Del otro lado del pago pasa todo lo interesante: la IA analiza las fotos para evaluar estado y calidad, un motor AVM (Automated Valuation Model) busca comparables reales de la zona y arma un rango de valor con nivel de confianza, y un generador de informes produce un PDF profesional que llega por email con un link de descarga.

Es un producto pago: $29.000 ARS con precio promocional de lanzamiento hasta el 1 de octubre de 2026 (después pasa a $75.000). Fue una decisión deliberada. Un número gratis en pantalla es un juguete; un informe pago con metodología y comparables es una herramienta que la gente usa para decidir si vende, a cuánto publica o cómo negocia. Sobre eso vuelvo más abajo, porque la decisión de cobrar condicionó buena parte del diseño técnico.

Lo que NO hace: no reemplaza una tasación presencial para fines legales o bancarios. Es una herramienta de decisión para dueños, compradores e inmobiliarias que necesitan un valor de referencia serio, rápido y sin depender de coordinar visitas. Si querés ver el pitch completo del producto, está en la página del tasador de propiedades con IA.

El wizard: cada paso es un lugar donde te pueden abandonar

El frontend es React + TypeScript + Vite, y el wizard fue donde más iteramos en UX. Cuando el usuario tiene que completar un formulario largo ANTES de pagar, cada campo es una oportunidad de abandono. Así que el criterio rector fue: pedir lo mínimo indispensable para que la tasación sea buena, y hacer opcional todo lo demás.

Los planos son opcionales, y eso importa

La versión inicial pedía planos de la propiedad. Tiene sentido desde el punto de vista del modelo: un plano te da superficie exacta, distribución, orientación. El problema es que casi nadie tiene el plano de su casa a mano. Pedirlo como requisito obligatorio corta el flujo en seco: el usuario dice "lo busco después" y no vuelve nunca.

Los hicimos opcionales para bajar fricción. Si el usuario los tiene, mejoran la precisión del análisis; si no los tiene, la tasación sale igual con los datos declarados y lo que la IA extrae de las fotos. Es el clásico trade-off entre calidad del input y tasa de completado, y en un producto de consumo masivo el completado gana casi siempre.

Las fotos van antes del pago

Otra decisión de orden: las fotos se cargan en el paso tres, antes de pagar. Podríamos haber cobrado primero y pedido las fotos después, pero eso genera un estado intermedio horrible: gente que pagó y nunca terminó de cargar, informes a medias, soporte. Con las fotos adelante, el usuario que llega al pago ya invirtió esfuerzo (efecto de compromiso) y del lado nuestro tenemos todo lo necesario para disparar el pipeline completo apenas se acredita el pago. Un solo estado feliz: pagó, se procesa, llega el informe.

Visión con OpenRouter: la IA que mira tus fotos

Cada foto que sube el usuario pasa por un modelo de visión vía OpenRouter. Del análisis extraemos señales estructuradas: qué tipo de ambiente es (cocina, baño, dormitorio, exterior), estado general de conservación, calidad de terminaciones, señales de refacción reciente o de deterioro. Todo eso sale como JSON con un prompt que fuerza el esquema, y se valida antes de entrar al modelo de valuación: si el modelo devuelve algo fuera de esquema, se reintenta.

¿Por qué OpenRouter y no ir directo contra un proveedor? Tres razones prácticas. Uno: un solo endpoint y una sola API key para visión y texto, lo cual simplifica las edge functions. Dos: cambiar de modelo es cambiar un string de configuración, no reescribir integración — y en visión los modelos mejoran cada pocos meses, así que esa flexibilidad se usa de verdad. Tres: si un proveedor tiene un mal día, el fallback a otro modelo es trivial. Para un producto donde el usuario ya pagó y está esperando su informe, no poder degradar con gracia no es opción.

El análisis de fotos no es decorativo: alimenta directamente la valuación. Una propiedad "a reciclar" y una "recién refaccionada" con la misma superficie y en la misma cuadra valen distinto, y esa diferencia no está en ningún dato estructurado que puedas cargar en un formulario sin aburrir al usuario. Está en las fotos.

El AVM: comparables cuando el dato público es ruidoso

Acá está el corazón del producto y el problema técnico más interesante. Un AVM por comparables suena simple: buscá propiedades parecidas en la zona, ajustá por diferencias, promediá. En países con registros públicos de transacciones funciona hermoso. En Argentina tenés un problema estructural: el dato público disponible es mayormente precio de publicación, no precio de cierre. Y entre lo que alguien pide y lo que alguien paga hay una brecha que además no es constante: varía por zona, por tipología y por momento del mercado.

Si tomás los precios de publicación como si fueran valores de mercado, tu tasador hereda el optimismo de todos los vendedores de la zona. Sesgo sistemático hacia arriba. ¿Cómo lo encaramos?

Primero, selección agresiva de comparables. No alcanza con "departamentos en el mismo barrio": filtramos por tipología, rango de superficie, antigüedad y características estructurales, y descartamos outliers — la publicación aspiracional que lleva meses clavada a un precio de fantasía mete más ruido que señal. Preferimos menos comparables buenos que muchos mediocres.

Segundo, ajustes explícitos. Cada comparable se ajusta por las diferencias contra la propiedad tasada: superficie, estado (acá vuelve a entrar el análisis de fotos), amenities, características del edificio o del lote. El resultado no es un promedio crudo sino una distribución de valores ajustados.

Tercero — y esto es lo más importante — honestidad estadística en el output. El informe no dice "tu casa vale X". Dice: el rango estimado es este, y el nivel de confianza es este. Si la zona tiene muchos comparables consistentes, la confianza es alta y el rango es angosto. Si hay pocos comparables o mucha dispersión, la confianza baja y el rango se abre. Mostrar la incertidumbre en vez de esconderla fue una decisión de producto tanto como técnica: un número único y seco es más "vendedor" a primera vista, pero es mentirle al usuario sobre la precisión que un modelo puede tener con los datos disponibles.

Por qué un informe PDF y no un número en pantalla

Esta pregunta nos la hicieron varias veces: si el resultado es un rango de valor, ¿para qué el PDF? ¿No alcanza con mostrarlo en pantalla?

No, y por tres razones que aprendimos a valorar:

Percepción de valor. Cobrás por algo, y ese algo tiene que existir como objeto. Un número en pantalla se olvida al cerrar la pestaña; un informe con tu dirección, tus fotos analizadas, tus comparables y la metodología explicada es un entregable que justifica lo que pagaste. La diferencia entre "me dijo un número" y "tengo el informe" es enorme en cómo el usuario percibe la transacción.

Es compartible. El caso de uso real de una tasación casi nunca es individual: se la mandás a tu pareja para decidir si venden, al comprador para justificar el precio, a la inmobiliaria para discutir a cuánto publicar. Un PDF viaja por WhatsApp y por email sin fricción. Un dashboard con login, no.

El formato obliga a mostrar el trabajo. Un informe de varias páginas no puede ser un número mágico: tiene que mostrar los comparables que se usaron, los ajustes, el análisis de las fotos, el racional del rango. Eso nos forzó a que el pipeline entero fuera explicable de punta a punta, que es exactamente la disciplina que un AVM necesita para no degenerar en una caja negra.

La generación corre server-side en las edge functions después de que el pipeline de valuación termina, y el usuario recibe un email con el link al informe. El email incluye además un botón de reportar problema: si algo del informe está mal o el usuario tiene dudas, el reclamo entra directo, con contexto, sin que la persona tenga que ir a buscar cómo contactarnos. En un producto pago, el camino del reclamo es parte del producto.

MercadoPago e idempotencia: cobrar exactamente una vez

El cobro es con MercadoPago Checkout, y acá va el consejo que le daría a cualquiera que integra pagos por primera vez: el happy path es trivial, todo lo demás es el trabajo. Los webhooks de MP pueden llegar más de una vez. El usuario puede refrescar la página de retorno. Puede pagar y cerrar la pestaña antes de volver al sitio. Puede intentar pagar dos veces porque la primera "no le anduvo".

La respuesta a todo eso es una sola palabra: idempotencia. Cada tasación tiene una referencia externa única que viaja en la preferencia de pago, y el procesamiento del pago está diseñado para que ejecutarlo N veces tenga el mismo efecto que ejecutarlo una. Cuando llega una notificación, verificamos el estado real del pago contra la API de MP (nunca confiar en el contenido de la notificación como fuente de verdad), chequeamos si esa tasación ya fue procesada, y si ya lo fue respondemos OK y no hacemos nada. El pipeline de valuación se dispara una sola vez por tasación pagada, sin importar cuántas veces nos entere MP de lo mismo.

Esto suena obvio escrito así, pero es el tipo de correctitud que no se ve en la demo y se ve clarísimo en producción: sin idempotencia, un webhook duplicado significa dos informes, dos emails, o peor, un estado inconsistente donde el usuario pagó y el sistema cree que no.

El stack, en frío

Para los que llegaron buscando la lista:

Frontend: React + TypeScript + Vite. El wizard es una máquina de estados simple con persistencia del progreso, para que un refresh no te mande al paso uno.

Backend: Supabase — Postgres para los datos y Edge Functions en Deno para todo el pipeline: análisis de fotos, motor de comparables, generación del informe, webhooks de pago y emails. Cero servidores propios que administrar.

IA: OpenRouter como gateway único para visión y texto, por la flexibilidad de modelos que conté arriba.

Pagos: MercadoPago Checkout, con el diseño idempotente descripto.

La virtud de este stack no es ninguna pieza individual: es que es el mismo stack del resto de AgonProp, la plataforma inmobiliaria de la que el tasador es parte. Mismos patrones, misma infraestructura, mismo deploy. Cuando sos un equipo chico, la consistencia del stack vale más que la optimización local de cada pieza.

Qué me llevo de este proyecto

Tres aprendizajes que exceden al tasador:

Primero: cuando el dato público es ruidoso, el diferencial no está en el modelo sino en el tratamiento del dato. Cualquiera puede promediar publicaciones; el trabajo real está en filtrar, ajustar y — sobre todo — comunicar la incertidumbre en vez de esconderla.

Segundo: en productos pagos de un solo uso, el entregable es el producto. El PDF no es un formato de salida, es la razón por la que la transacción se siente justa.

Tercero: la infraestructura de pagos se diseña para el caos, no para la demo. Idempotencia desde el día uno, siempre.

Si tenés una propiedad y querés ver el resultado de todo esto en acción, podés tasar tu propiedad online ahora: cargás los datos y las fotos, y en minutos tenés el informe en tu casilla. Y si estás construyendo algo parecido y te trabaste en alguno de estos problemas, escribime — este tipo de casos son exactamente lo que me divierte destrabar.