DEV Community: Multita

Rendimiento en un sitio estático de 1.382 páginas: qué medimos con Lighthouse y qué no sirve medir

Multita — Fri, 23 Oct 2026 12:00:00 +0000

Tenemos un sitio estático de 1.382 páginas hecho con Astro y publicado en Cloudflare. Esta semana lo medimos con Lighthouse 13 contra producción para ver si las páginas nuevas (un directorio de registros y varias notas) bajaban los puntajes. Estos son los números y lo que aprendimos al medir.

Los resultados

Cinco páginas de plantillas distintas, medidas en modo escritorio simulado de Lighthouse:

Página	Rendimiento	Accesibilidad	Buenas prácticas	SEO	LCP
Directorio (portada)	98 y 100 en dos corridas	100	100	100	2,1 s y 1,6 s
Provincia	99	100	100	100	1,9 s
Registro individual	98	100	100	100	2,1 s
Nota larga con tablas	99	100	100	100	1,9 s
Nota sobre consultas	99	100	100	100	1,9 s

El desplazamiento del diseño (CLS) dio entre 0 y 0,002, y el tiempo de bloqueo (TBT) dio 0 ms en todas.

Lo primero: dos puntos son ruido

La misma página del directorio dio 98 en una corrida y 100 en la siguiente. La portada del sitio, que usamos de referencia, dio 98 en esa misma tanda. Una diferencia de uno o dos puntos entre corridas del mismo código no es una regresión: es variación del entorno de medición. Antes de buscar un problema, repetí la medición.

Qué ayudó, en concreto

Scripts propios con hash y minificados. En el build, los scripts de la carpeta pública se renombran con un hash de su contenido y se minifican. En una corrida del build bajaron de 106,2 KB a 36,1 KB (66% menos), con las referencias reescritas en todas las páginas.
Módulos cargados después del primer pintado. Los scripts que no hacen falta para ver la página se cargan con baja prioridad.
Un solo script en línea, habilitado por hash. La política de seguridad de contenido (CSP) permite ese script por su hash, sin abrir unsafe-inline.
Sin analítica de terceros en las páginas. No cargamos Google Analytics ni etiquetas de seguimiento: medimos el tráfico con Search Console. Cada script externo cuesta puntos de rendimiento, y el dato que aporta ya lo da el buscador.

Qué medir y cómo

Una página por plantilla, no solo la portada. Una prueba de accesibilidad de la portada nunca va a encontrar un problema de contraste que vive en otra plantilla. En nuestro caso, un enlace dentro de un párrafo gris daba contraste insuficiente solo en la página de la API.
Rendimiento contra producción, el resto en local. Cloudflare comprime el HTML y en local no se reproduce, así que el puntaje de rendimiento local sale peor de lo que es. Accesibilidad, buenas prácticas y SEO sí se pueden medir en local con las mismas cabeceras de seguridad.
No lo corras en cada build. Necesita un navegador y tarda unos 30 segundos por página. Lo corremos antes de cambiar una plantilla o los estilos.

Un detalle que nos engañó

Una página de una calculadora salía en rojo en buenas prácticas en el entorno local por un error 502 en la consola del navegador. Era el servicio de valores que no existe en local. En producción, la misma página daba 100 y cero errores. Antes de tocar código, confirmá el problema contra producción.

Las páginas medidas son parte del sitio: podés ver el directorio de registros del automotor o la sección de herramientas y medirlas por tu cuenta.

Contrastamos las notas de un sitio de trámites con las normas oficiales y encontramos errores en una decena

Multita — Tue, 20 Oct 2026 12:00:00 +0000

Un sitio de trámites vive de que sus números sean ciertos: plazos, descuentos, puntos de la licencia. Hicimos algo que casi nadie hace después de publicar: volver a cada nota con mayor tráfico y contrastar cada cifra con la norma o la página oficial. Encontramos errores en una decena de notas. Acá van los patrones, porque sirven para cualquier contenido que cite normas.

Los errores, por tipo

1. Un plazo atribuido a una ley que no lo fija. La nota sobre el descargo de una multa decía "5 días hábiles". La Ley 13.927 de la Provincia de Buenos Aires no fija ese plazo: lo deja a la reglamentación. El Decreto 532/09 lo establece en 15 días desde el vencimiento del pago voluntario. Los 5 días son para apelar la sentencia, que es otra cosa.

2. Un descuento con el plazo equivocado. Una nota decía que en la Ciudad se paga con 50% de descuento dentro de los 30 días corridos. La Ley 451 (art. 18) dice 40 días corridos y agrega algo que nadie contaba: si pedís la intervención del controlador dentro de ese plazo y resultás condenado, la bonificación es del 25%.

3. Una consecuencia exagerada. Varias notas decían que al llegar a cero puntos "te suspenden el registro". Según la página oficial de la Ciudad, se inicia un trámite de inhabilitación: 60 días la primera vez, y desde la segunda caduca la licencia.

4. Un adjetivo en lugar de un dato. "Cruzar en rojo es una falta grave que descuenta muchos puntos" no ayuda a nadie. La tabla oficial dice 5 puntos. Reemplazamos el adjetivo por el número, con la fuente.

5. Una fuente que no decía lo que la nota le atribuía. Una nota sobre el pago voluntario citaba una página oficial como respaldo, pero esa página no habla del pago voluntario. El respaldo real era el decreto.

6. Un matiz que cambia el sentido. Una nota decía que la Unidad Fija equivale a "un litro de nafta premium". El decreto dice "nafta de mayor octanaje", que es una definición distinta.

Qué hicimos

Una jerarquía de fuentes. La norma publicada manda. Después, la página oficial del organismo. Los medios y los sitios de consulta de terceros no alcanzan para afirmar un plazo.
"No pude verificarlo" es una respuesta válida. Cuando una cifra solo aparecía en sitios de terceros que se contradecían (por ejemplo, el plazo de pago voluntario de un municipio), la nota pasó a decir que el plazo figura en el acta y que las fuentes no coinciden. Perder precisión aparente es mejor que publicar un número falso.
Pruebas que impiden repetir un error corregido. Para el error más grave del rubro (decir que las multas frenan una transferencia, cuando el DNU 70/2023 lo eliminó) hay una prueba que falla el build si cualquier nota lo vuelve a escribir.
Fecha y fuente en cada dato. Una cifra sin fecha envejece sin que nadie lo note.

Qué nos llevamos

Los errores no vinieron de mala fe sino de copiar el plazo de una norma a otra, de resumir de más y de confiar en la primera página que aparece en un buscador. Revisarlo cuesta unas horas y evita que una persona pierda un descuento o un plazo por un dato nuestro.

Si te sirve de ejemplo, así quedaron dos de las notas: cómo hacer el descargo de una multa y cómo funciona el scoring de la licencia en CABA, con la tabla de puntos y la fuente oficial. La Ley 451 está publicada para quien quiera contrastar.

Cómo calcular el MRPA, el nuevo arancel del Registro Automotor, con la API de la UVA del BCRA

Multita — Fri, 16 Oct 2026 12:00:00 +0000

Desde el 1 de septiembre de 2026, los aranceles del Registro Automotor dejaron de expresarse en pesos. Ahora se expresan en MRPA (Módulo de Registro de la Propiedad del Automotor), una unidad que creó la Resolución 308/2026 del Ministerio de Justicia. Si hacés software que calcula costos de trámites del automotor, necesitás el valor del MRPA en pesos, y se calcula con datos públicos.

La fórmula

Según la resolución:

Un MRPA vale media UVA (0,5 UVA).
La UVA que se toma es la del BCRA del día hábil anterior al inicio del período.
El valor se actualiza cada cuatro meses y se redondea hacia abajo a un múltiplo de $10.

La resolución está en el Boletín Oficial, y el anexo de aranceles de la DNRPA fija cuántos MRPA cuesta cada trámite.

De dónde sale la UVA

El BCRA publica la UVA en su API de estadísticas. La versión que anda es la 4.0; las anteriores (2 y 3) están dadas de baja:

https://api.bcra.gob.ar/estadisticas/v4.0/Monetarias/31?desde=2026-08-31&hasta=2026-08-31

La respuesta trae la fecha y el valor. Para el 31 de agosto de 2026, el valor es 2.096,27.

El cálculo en código

const BCRA_UVA = 'https://api.bcra.gob.ar/estadisticas/v4.0/Monetarias/31';

async function uvaDelDia(fechaISO) {
  const r = await fetch(`${BCRA_UVA}?desde=${fechaISO}&hasta=${fechaISO}`);
  const j = await r.json();
  const detalle = j.results?.[0]?.detalle;
  return detalle?.length ? detalle[0].valor : null; // si no hay cotización, viene vacío
}

// Media UVA, redondeada hacia abajo al múltiplo de $10
const mrpa = (uva) => Math.floor((uva * 0.5) / 10) * 10;

const uva = await uvaDelDia('2026-08-31'); // 2096.27
console.log(mrpa(uva));      // 1040
console.log(32 * mrpa(uva)); // 33280

La cuenta: 0,5 × 2.096,27 = 1.048,135, y redondeado hacia abajo al múltiplo de $10 da $1.040.

Qué sale con eso

Con el MRPA de septiembre a diciembre de 2026 en $1.040:

Trámite	MRPA	Pesos
Transferencia de dominio (mínimo)	32	$33.280
Informe de dominio	4	$4.160
Denuncia de venta	4	$4.160
Certificación de firma adicional	3	$3.120

Para la transferencia, el arancel es el 1% del valor del vehículo, con ese mínimo de 32 MRPA.

Cosas que conviene saber

Hay valores circulando que no coinciden. Al comparar páginas que publican el arancel, vimos cifras de $1.027,50 y de $1.050. Con la UVA oficial del día correspondiente, la cuenta da $1.040. Verificá siempre contra el dato original.
El período cambia cada cuatro meses. Tenés que recalcular a comienzos de enero, mayo y septiembre, con la UVA del último día hábil anterior. Nosotros lo dejamos como tarea programada.
Manejá la respuesta vacía. Si la fecha no tiene cotización, el arreglo viene sin elementos. Una cuenta con undefined te da un arancel de NaN.
Guardá la fecha de cálculo. Mostrar "arancel al período septiembre a diciembre de 2026" evita que alguien lea un número vencido.

Los resultados con costos completos (arancel, sellos provinciales y verificación) están en cuánto cuesta transferir un auto, y el costo de pedir el informe de dominio también se expresa en MRPA. El estimador oficial de la DNRPA sigue siendo la referencia final para un trámite concreto.

Modelar el ciclo de vida de una multa de tránsito como máquina de estados, con los plazos reales

Multita — Tue, 13 Oct 2026 12:00:00 +0000

Cuando se modela una multa de tránsito, lo primero que aparece es un campo debe: true/false. Es el error más común. Una infracción pasa por etapas, y cada etapa tiene un plazo que cambia el monto y las opciones de quien la recibe. Si el modelo no las distingue, el software le dice a alguien que "todavía puede pagar con descuento" cuando el plazo venció hace una semana.

Las etapas

De forma simplificada, el recorrido de una multa es:

Labrada y notificada. El reloj de los plazos suele empezar con la notificación.
Pago voluntario. Pagar reconociendo la infracción, con descuento.
Descargo. Presentar la defensa ante el juzgado, si no se pagó.
Sentencia. El juez resuelve.
Apelación. Un plazo corto para recurrir.
Firme. Si no se apeló o la apelación fracasó. Puede terminar en apremio (cobro judicial).

Los plazos, con su fuente

Esto es lo que pudimos verificar en las normas, y lo que no:

Provincia de Buenos Aires. El Decreto 532/09 fija 30 días desde la notificación para acogerse al pago voluntario (50% sobre el mínimo en UF). Si no se paga, hay 15 días desde el día siguiente al vencimiento para presentar el descargo, que el juez puede ampliar. La Ley 13.927 (art. 40) da 5 días para apelar la sentencia. El texto que consultamos no aclara si los 30 y los 15 días son hábiles o corridos.
Ciudad de Buenos Aires. La Ley 451 (art. 18) da 50% de bonificación por pago voluntario dentro de los 40 días corridos de notificado, y 25% si se pide la intervención del controlador dentro de ese plazo y hay condena. En el texto consultado no figura el plazo del descargo.
Excepciones. En la Provincia, si el acta se labra en el acto, funciona como boleta de citación y hay que presentarse dentro de los 30 días corridos de la infracción. Para las fotomultas, la notificación debe llegar dentro de los 60 días hábiles.

Puede haber decretos modificatorios, así que el plazo que vale es el que dice la notificación.

El código

La idea central: no guardes el estado, derivalo de las fechas y de las reglas de cada lugar.

const DIA = 24 * 60 * 60 * 1000;

const REGLAS = {
  // Decreto 532/09: 30 días de pago voluntario, 15 de descargo
  pba: { voluntario: 30, descargo: 15 },
  // Ley 451, art. 18: 40 días corridos de pago voluntario; descargo no verificado
  caba: { voluntario: 40, descargo: null },
};

const sumarDias = (fecha, dias) => new Date(fecha.getTime() + dias * DIA);

function plazos(regla, notificada) {
  const r = REGLAS[regla];
  const finVoluntario = sumarDias(notificada, r.voluntario);
  return {
    finVoluntario,
    finDescargo: r.descargo == null ? null : sumarDias(finVoluntario, r.descargo),
  };
}

function estado(regla, notificada, hoy, { pagada = false } = {}) {
  if (pagada) return 'pagada';
  const p = plazos(regla, notificada);
  if (hoy <= p.finVoluntario) return 'pago_voluntario';
  if (p.finDescargo === null) return 'plazo_de_descargo_desconocido';
  if (hoy <= p.finDescargo) return 'descargo_abierto';
  return 'a_resolver';
}

const n = new Date('2026-09-01T00:00:00Z');
estado('pba', n, new Date('2026-09-20T00:00:00Z'));  // "pago_voluntario"
estado('pba', n, new Date('2026-10-05T00:00:00Z'));  // "descargo_abierto"
estado('pba', n, new Date('2026-10-30T00:00:00Z'));  // "a_resolver"
estado('caba', n, new Date('2026-11-30T00:00:00Z')); // "plazo_de_descargo_desconocido"

Las decisiones que importan

"Desconocido" es un estado, no un valor por defecto. Para la Ciudad no teníamos el plazo del descargo. En lugar de inventar uno, el modelo devuelve plazo_de_descargo_desconocido, y la pantalla puede decir "revisá la notificación".
Las reglas viven en un solo lugar, con su fuente. Un objeto por jurisdicción, con el artículo al lado. Cuando cambia una norma se cambia un número y se ve de dónde sale.
Hábil o corrido es un dato, no un detalle. Si la norma no lo aclara, guardalo como pendiente de confirmar. Sumar 30 días corridos cuando eran hábiles te da una fecha incorrecta.
El reloj arranca en la notificación. No en la fecha de la infracción, salvo las excepciones que la norma indique.
La prescripción tiene su propio reloj. Es independiente de estas etapas y se modela aparte.

Y para quien solo quiere el resumen

Si lo que querés es la versión para conductores, la explicamos en cómo hacer el descargo de una multa y en cómo funciona el pronto pago en Provincia. En un artículo anterior contamos cómo unificamos más de 30 sistemas de multas en una sola API.

Cómo armamos un directorio de 1.482 registros del automotor con datos abiertos del DNRPA

Multita — Fri, 09 Oct 2026 00:25:35 +0000

Hacer un trámite del automotor en Argentina empieza por una pregunta simple: ¿a qué registro seccional tengo que ir? La respuesta existe, pero está repartida entre listados viejos, blogs que copian planillas y una consulta oficial que pide la dirección exacta del titular.

El Portal de Datos Justicia publica el listado oficial de Registros Seccionales del DNRPA como un CSV, bajo licencia CC BY 4.0, y lo actualiza todos los meses. Con eso armamos un directorio de 1.482 registros de las 24 provincias, con dirección, teléfono y horario. Está en https://multita.com.ar/registros-automotor y estos son los problemas que tuvimos.

1. Los datos crudos no se pueden publicar tal cual

El CSV trae nombres sin tildes, mayúsculas por todos lados y domicilios con formatos distintos. Armamos un script que:

Pasa los nombres a capitalización normal y restituye las tildes con un diccionario de localidades y partidos.
Corrige los pocos casos que el diccionario no cubre con un mapa de excepciones a mano.
Descarta lo que no hace falta y es personal: el CSV incluye datos del encargado, y los dejamos afuera.

2. Un test de integridad encontró un error que no vimos a ojo

Escribimos una prueba que revisa cada registro generado. Falló en los teléfonos: algunos quedaban como () porque la fuente traía el campo vacío con paréntesis. El filtro ahora cuenta dígitos: si hay menos de seis, no hay teléfono y la página dice que no está informado.

Las otras pruebas revisan que el archivo no esté truncado (más de 1.400 registros y las 24 provincias), que cada registro traiga código, denominación, dirección y provincia, que dos grupos de una misma provincia no compartan URL y que la fecha de los datos sea válida y no futura. Otra prueba confirma que no se guardan datos personales del encargado.

3. Una página por localidad, generada en el build

El sitio está hecho con Astro y se genera de forma estática: una portada con buscador, una página por provincia y una por localidad, unas 400 en total. Donde varios registros comparten localidad (en la Ciudad de Buenos Aires son todos "Capital Federal") hay una sola página con la lista.

El título y la descripción de cada página se arman con una cadena de opciones de más larga a más corta, y se usa la primera que entra en el límite. Así ninguna queda cortada en el resultado de búsqueda.

4. Un buscador sin servidor

El buscador de la portada carga un índice JSON liviano y filtra en el navegador, sin tildes ni mayúsculas, por localidad, partido, número de registro o código postal. No hay backend ni base de datos: es un archivo que se genera en el build.

5. La licencia y la fuente, a la vista

CC BY 4.0 pide atribución. Cada página cita el listado oficial, su fecha ("datos al 5 de octubre de 2026") y aclara que Multita no es un organismo oficial: hay que confirmar el horario y sacar turno antes de ir.

6. Actualización mensual

El mismo script baja el CSV vigente y reescribe el JSON. Lo corremos cada mes, revisamos el diff (registros nuevos, bajas, cambios de domicilio y horario), ejecutamos las pruebas y publicamos.

Qué aprendimos

Con datos abiertos oficiales, la parte que más cuesta es limpiar y verificar, no armar la página.
Una prueba que mira la salida real encuentra errores que una revisión de código no ve.
Citar la fuente y la fecha en cada página es parte del producto, no un trámite de la licencia.

El directorio está acá: https://multita.com.ar/registros-automotor. Si ves un dato desactualizado, avisanos.

App para consultar multas de tránsito en Argentina: 32 jurisdicciones desde el celular, sin Play Store

Multita — Tue, 08 Sep 2026 12:32:23 +0000

Si manejás en Argentina, sabés el problema: para saber si un auto tiene multas hay que entrar a un sistema distinto por cada provincia y cada municipio, cada uno con su captcha y sus horarios de caída. Un mismo auto puede deber en tres lados a la vez, y es facilísimo mirar uno solo y quedarse tranquilo de más.

Hicimos una app que resuelve eso en una sola búsqueda. Se instala en el celular en unos segundos, es gratis, no pide un solo permiso y no está en ninguna tienda.

Este post es las dos mitades: qué hace, por si te sirve usarla, y cómo la construimos sin pasar por Google Play ni la App Store, por si te sirve copiar el enfoque.

Qué hace, concretamente

Multita busca por patente, DNI o CUIT y consulta 32 jurisdicciones argentinas de una vez, entre provinciales y municipales. Devuelve cada acta con su estado y su monto en pesos.

El detalle que importa: no te muestra un número guardado. Cuando buscás, entra a los sistemas oficiales en ese momento y convierte cada acta a pesos con el valor vigente de su jurisdicción.

Eso no es un capricho de arquitectura. En Argentina las multas no están escritas en pesos, están escritas en Unidades Fijas, y cada jurisdicción actualiza la suya cuando quiere. En septiembre pasó dos veces en dos días: Provincia de Buenos Aires movió la suya un 0,44% el día 1, y la Ciudad la movió un 23,5% el día 2. El mismo auto, con actas de los dos lados, tiene dos aumentos distintos la misma semana. Un valor cacheado ahí no es un dato viejo: es un número inventado.

Cómo se instala, sin tienda

Android (Chrome): entrás a multita.com.ar y aparece el aviso de instalar. Si no aparece, menú de tres puntos, "Instalar aplicación".

iPhone (Safari): botón de compartir, "Agregar a inicio". Tiene que ser Safari, que es el único navegador del iPhone que lo permite.

Queda con ícono propio, abre en su ventana sin barra de direcciones y arranca directo en la pantalla de consulta. Si mantenés apretado el ícono, tenés tres atajos: consultar, generar un descargo y novedades.

Nada de esto descarga cuarenta megas ni pide acceso a tus contactos.

Por qué no la publicamos en una tienda (todavía)

Las ventajas son reales y vale enumerarlas sin romanticismo:

Cero permisos. No los necesita, así que no los pide. Eso solo ya cambia la conversión: nadie abandona en una pantalla de permisos que no existe.
Cero espacio. Pesa lo que pesa una página.
Cero actualizaciones. Siempre abre la última versión. No existe el usuario trabado tres releases atrás.
Una sola base de código y un solo deploy. No hay build de Android, ni de iOS, ni esperar una review por arreglar una coma.

Y lo que se pierde, que también es real: no aparecés en el buscador de la tienda, que para mucha gente sigue siendo donde se buscan las apps, y no tenés la ficha con reseñas que da confianza. Por eso estamos armando igual la versión de Play. Pero no era un prerrequisito para tener la app funcionando, y esa es la parte que se suele asumir mal.

La parte difícil: el cache que puede mentirte

Acá viene lo técnico, y es lo único de todo esto que fue realmente delicado.

Una PWA necesita un service worker, que es un proxy que vos escribís entre la app y la red. Es lo que la hace instalable y lo que la hace abrir sin señal. También es lo que puede mentirle a tu propia aplicación.

En nuestro caso hay una complicación poco común: una consulta es un job largo y durable. Tarda minutos, se registra en la base, el browser la va poll-eando y un cron cierra los jobs que quedaron sin nadie mirando. Toda esa maquinaria existe por un bug caro: cuando el resultado dependía de que el browser polleara hasta el final, cerrar la pestaña equivalía a perder la consulta.

Ahora ponele un cache adelante. Dos reglas que no se negocian:

La ruta del poll no se cachea. Nunca.

if (url.pathname.startsWith('/api/')) return;  // a la red, siempre

Si el service worker contesta una sola vez desde el cache, le miente al poll sobre el estado de un job: el browser cree que la consulta sigue corriendo cuando terminó, o al revés. Sería reintroducir, desde la capa que agregamos para mejorar la experiencia, exactamente el bug que toda la maquinaria de jobs existe para evitar.

Las pantallas con token en la URL tampoco.

La pantalla de una consulta en curso lleva en la URL un token que es la llave del resultado. Cachearla dejaría esa llave escrita en el disco del teléfono, sobreviviendo a la pestaña, a cambio de nada: sin red esa pantalla no sirve igual, porque su contenido viene de la API que por la regla anterior no está cacheada. Todo el riesgo, cero beneficio.

Hay una tercera que no es de seguridad sino de buenos modales: el sitio tiene más de 900 páginas, así que el cache de páginas tiene un techo de 40. Sin eso, alguien que navega una tarde se lleva medio sitio al disco sin haberlo pedido, gastando sus datos.

Sin señal: qué anda y qué no

Es donde más se promete de más en los posts de PWA, así que va derecho:

La app abre sin señal, con su propia pantalla en lugar del dinosaurio, y lo que ya visitaste se sigue viendo.
La consulta no anda sin señal, y es el diseño, no una limitación. No hay copia de tus multas en el teléfono. Se entra a los organismos en el momento. Un resultado guardado sería un número viejo, y ya vimos lo que hace un 23,5% de golpe.

"La app abre offline" y "la app funciona offline" son cosas distintas, y conviene tenerlo claro antes de escribir la primera línea de service worker.

Probala

Se instala desde multita.com.ar en Android y iPhone. Gratis, sin registro, sin tienda.
El paso a paso con el detalle de cada teléfono está en cómo instalar la app para consultar multas.
Si querés integrarlo a lo tuyo, la API devuelve las 32 jurisdicciones en JSON, con cada acta ya convertida a pesos al valor vigente de la suya.
Y si te quedaste con la duda de los saltos: CABA subió 23,5% de un día para el otro mientras Provincia subía 0,44%.

Si estás por meterle un service worker a algo, la pregunta que más rinde no es qué cachear, sino qué pasa si servís esta respuesta justo cuando cambió. Para la mayoría de las rutas la respuesta es "nada". Para dos o tres, es todo el producto.

La UF de CABA subió 23,5% de golpe: por qué un valor semestral es más peligroso de cachear

Multita — Wed, 02 Sep 2026 05:06:49 +0000

El 2 de septiembre de 2026 la Unidad Fija de la Ciudad de Buenos Aires pasó de $949,99 a $1.173,08. Un 23,5% de una sola vez. El día anterior, la Provincia de Buenos Aires había movido la suya un 0,44%.

Los dos valores miden lo mismo: el precio de la nafta de mayor octanaje. Los dos definen cuánto sale una multa de tránsito. Y sin embargo uno saltó cincuenta veces más que el otro.

La diferencia no es económica, es de calendario. Y si te tocó alguna vez sincronizar un valor oficial que publica un tercero, ahí hay una trampa que vale la pena mirar de cerca.

Los dos relojes

Provincia de Buenos Aires: la UF equivale a un litro de nafta premium y se ajusta cada dos meses. Sus últimos saltos: +2,53% en julio, +0,44% en septiembre.
CABA: la UF equivale a medio litro y la fija el Instituto de Estadística de la Ciudad cada seis meses (Ley 451, art. 20). Sus últimos saltos: +19,0% en marzo, +23,5% en septiembre.

Misma variable de fondo, misma inflación, resultados completamente distintos en la pantalla. Uno reparte el aumento en pedacitos, el otro lo acumula y lo suelta entero.

Por qué esto importa si lo tenés cacheado

Acá está el punto que me interesa.

Supongamos que guardás los dos valores con la misma política. Un TTL de seis horas, un scraper diario, un fallback al último valor conocido si la fuente no responde. Suena razonable y es lo que casi todos hacemos.

El problema es que el costo de servir un dato viejo no es el mismo para los dos.

Si tu copia de la UF bonaerense se queda vieja un bimestre entero, mostrás un número con un 0,44% de error. Nadie se entera, y si se entera no le cambia la decisión.

Si tu copia de la UF porteña se queda vieja un solo día, el 2 de septiembre, mostrás un número con un 23,5% de error. Sobre la multa más cara de la Ciudad eso son $892.360 de diferencia en una sola acta.

Mismo sistema, misma política de caché, mismo tipo de dato. Dos órdenes de magnitud de diferencia en el daño.

La conclusión es incómoda para el instinto de ingeniería, que tiende a tratar uniforme lo que tiene la misma forma:

La frecuencia de actualización de un valor y su volatilidad por actualización están inversamente correlacionadas. Cuanto menos seguido cambia algo, más grande es el salto cuando cambia. Así que "cambia poco" no significa "es seguro cachearlo": puede significar exactamente lo contrario.

Lo que cambia en la práctica

Lo que sacamos de esto no fue bajar el TTL a todo, que es la respuesta perezosa y encima te tira la fuente abajo a pedradas.

Fue empezar a guardar la ventana de validez junto con el valor.

El dato oficial de CABA no viene solo. Viene con las fechas: rige del 2 de septiembre de 2026 al 1 de marzo de 2027. Esa segunda fecha es tan dato como el número, y es la que convierte una pregunta difícil en una comparación trivial.

// Antes: "¿estará viejo?" es una corazonada.
const uf = await cache.get('uf:caba');

// Después: la propia fuente te dice hasta cuándo vale.
const uf = await cache.get('uf:caba');   // { valor, desde, hasta }
if (uf && Date.now() > Date.parse(uf.hasta)) {
  // no adivines: sabés que caducó
  await revalidar('caba');
}

Con eso, el 2 de septiembre no dependés de que el scraper haya corrido a tiempo ni de que alguien se acuerde: el valor guardado se declara vencido solo. Y lo mismo aplica a un valor bimestral, salvo que ahí la ventana es más corta y el riesgo de equivocarse, mucho menor.

El corolario práctico, para cualquier dato oficial de este tipo (una tasa, un índice, un valor de referencia legal): si la fuente publica una fecha de vigencia, guardala. Es la diferencia entre revalidar por reloj y revalidar por contrato.

La otra mitad: qué hacés cuando sí caducó

Que el sistema sepa que el dato venció no significa que pueda conseguir el nuevo. La fuente puede no haberlo publicado todavía, o estar caída, o cambiar el HTML justo ese día.

Ahí el orden de preferencia que nos quedó es:

Valor vivo validado. Si responde y pasa las validaciones (que sea un número, que sea positivo, que no se haya movido un 900% de golpe), ese.
Último valor conocido, marcado como vencido. Se sigue mostrando, porque un número de hace un semestre es infinitamente más útil que un guion, pero el sistema sabe que está en deuda y lo reintenta.
Nunca un vacío.

Y una validación que suena paranoica hasta que la necesitás: acotar el salto. Un ajuste del 23,5% es real y tiene que pasar. Uno del 2.300% es un scraper leyendo mal un separador de miles. La diferencia entre los dos es un if, y de un lado de ese if está publicar montos equivocados en una página que la gente usa para decidir si paga una multa.

Datos, por si llegaste buscando el número

	Valor de 1 UF	Cada cuánto se ajusta	Último salto
CABA	$1.173,08 (2-sep-2026 al 1-mar-2027)	Semestral	+23,5%
Provincia de Buenos Aires	$2.281 (septiembre-octubre 2026)	Bimestral	+0,44%

Un detalle lindo que salió de mirar los dos juntos: como la UF porteña es medio litro y la bonaerense un litro, la primera debería rondar la mitad de la segunda. Antes del ajuste estaba en el 41,6% de la de Provincia, o sea atrasada. Después quedó en el 51,4%. El salto del 23,5% no fue un aumento por encima de la inflación: fue ponerse al día de golpe.

El desglose con los montos por infracción está en el aumento de multas en CABA, y el de Provincia en su propia nota.
Si querés el concepto desde cero, qué es la Unidad Fija lo explica con el histórico de las dos jurisdicciones.
Todo esto sale de Multita, que consulta infracciones en 32 jurisdicciones argentinas. Si lo tuyo es integrarlo, la API las devuelve en JSON con cada acta ya convertida a pesos al valor de UF vigente de su jurisdicción, que es precisamente el problema de este post resuelto del lado del servidor.

Si tenés un valor oficial cacheado en algún lado, andá a fijarte si guardás su fecha de vencimiento. Si no la guardás, tu sistema no sabe que el dato venció: se está enterando cuando alguien se queja.

Valor de la UF en septiembre de 2026: subió a $2.281, y cómo evitamos que el dato quede viejo

Multita — Tue, 01 Sep 2026 21:37:24 +0000

La Unidad Fija (UF), el número con el que se calculan todas las multas de tránsito en la Provincia de Buenos Aires, pasó a $2.281 en septiembre de 2026. Venía de $2.271 en el bimestre julio-agosto: una suba del 0,44%, bastante menor que el 2,53% del ajuste anterior. En la Ciudad de Buenos Aires no se movió, sigue en $949,99, porque allá el ajuste es semestral y no bimestral.

Ese es el dato que la gente busca. Y es, exactamente, el dato que se nos quedaba viejo en medio sitio cada dos meses.

Este post cuenta cómo lo resolvimos, porque el problema es más general de lo que parece: un valor oficial, publicado por un tercero, que cambia en una fecha que no controlás y sin avisarte. Si alguna vez publicaste un precio de dólar, una tasa, un índice de inflación o un valor de referencia legal, es el mismo problema.

Por qué una multa no está en pesos

En Argentina una infracción de tránsito no se expresa en un monto fijo. Se expresa en Unidades Fijas. La norma dice que una infracción vale una cantidad de UF, y aparte, otro organismo fija cuánto vale una UF.

monto = cantidad_de_UF_de_la_infracción * valor_vigente_de_la_UF

En la Provincia de Buenos Aires una UF equivale al precio de un litro de nafta de mayor octanaje, y el Ministerio de Transporte la ajusta cada dos meses. En la Ciudad de Buenos Aires equivale a medio litro, la fija el Instituto de Estadística de la Ciudad y el ajuste es semestral. Dos fuentes, dos ritmos, cero webhooks.

La consecuencia de producto es fuerte: el monto de una deuda no se puede guardar. Hay que recalcularlo cada vez, con el valor vigente. Una multa del año pasado vale más hoy sin que nadie haya hecho nada.

Y la consecuencia técnica es este post.

El estado inicial, que es el estado de casi todos

El número arrancó donde arrancan todos los números: escrito en el lugar donde hacía falta. Un artículo decía "la UF vale $2.271". Otro también. La calculadora tenía su constante. La página de valores tenía la suya.

Trece lugares. Ninguno sabía de los otros.

Mientras el valor no cambia, esto no duele. El problema es que cambia cada dos meses, y actualizar trece archivos a mano tiene una tasa de éxito que no es 100%. Nunca es 100%. Lo que pasa en la práctica es que actualizás los tres que te acordás, los que salen primero en la búsqueda, y los otros diez siguen mostrando el valor del bimestre pasado.

Ahí el costo deja de ser técnico. Un sitio que publica cifras oficiales y muestra dos cifras distintas para la misma cosa pierde exactamente lo único que vende, que es que el número sea confiable. Peor todavía cuando buena parte del tráfico viene de gente buscando "cuánto vale la UF", y hoy también de modelos de lenguaje que leen la página y la citan. Un LLM que encuentra dos valores contradictorios en el mismo dominio no elige el correcto: te descarta como fuente.

Capa 1: una sola fuente, aburrida a propósito

Lo primero fue lo obvio. Un módulo, sin dependencias, que exporta los valores y nada más.

// uf.values.mjs
export const UF_PBA = 2281;
export const UF_CABA = 949.99;
export const UF_VIGENTE = 'septiembre 2026';

Dos decisiones chicas que después valieron mucho:

Es .mjs, no .ts. Porque lo tiene que importar el sitio, pero también el archivo de configuración del build, que corre en Node antes de que exista cualquier transpilación. Un .ts ahí obliga a un paso extra o a duplicar el valor, que es justo lo que estábamos sacando.

No tiene lógica de negocio. Es un archivo que se puede abrir, leer en tres segundos y editar sin entender el resto del sistema. Cuando el Estado publique el próximo ajuste, la tarea es cambiar dos números. Si para actualizar la UF hay que entender la arquitectura, alguien la va a actualizar mal.

Capa 2: tokens que se resuelven en el build

La parte difícil no era el código, era el contenido. Los artículos son Markdown. No pueden importar un módulo.

La solución fue meter tokens en el texto y resolverlos como paso del build:

A {{uf:vigente}} la UF de Provincia quedó en **{{uf:pba}}**.
La multa más cara, de 1.000 UF, llega a {{uf:pba*1000}}.

El resolver es un par de líneas, y la única gracia es que soporta multiplicación, porque la mitad de las menciones en los textos no son "el valor de la UF" sino "cuánto sale una infracción de 300 UF":

export function resolveUfToken(expr) {
  const e = String(expr || '').trim();
  if (e === 'vigente') return UF_VIGENTE;

  const m = /^(pba|caba)(?:\s*\*\s*(\d+(?:[.,]\d+)?))?$/.exec(e);
  if (!m) return null;                    // null = token inválido, ver capa 3

  const base = m[1] === 'pba' ? UF_PBA : UF_CABA;
  const mult = m[2] ? Number(m[2].replace(',', '.')) : 1;
  if (!Number.isFinite(mult) || mult <= 0) return null;

  return formatearPesos(base * mult);
}

Se engancha como integración del build, que en Astro es un hook, pero el patrón es el mismo en cualquier generador estático: interceptar el contenido antes de que se escriba el HTML.

Ahora actualizar la UF es editar dos números. Los 151 tokens repartidos en 16 archivos se resuelven solos.

Capa 3: la que importa de verdad

Acá está la parte que quiero dejar escrita, porque es la que se suele omitir.

Cuando armás un sistema de sustitución, el modo de falla no es que el número salga mal. El modo de falla es que salga {{uf:pba}}. Un token crudo, publicado, en la página que la gente lee y que los buscadores indexan. Es peor que el valor viejo: el valor viejo se ve como un error de actualización, el token crudo se ve como un sitio roto.

Un typo alcanza. {{uf:pva}} en lugar de {{uf:pba}}. El regex no matchea, el reemplazo no ocurre, y si tu resolver es tolerante devolvés el string original y lo publicás.

Por eso el resolver devuelve null en vez de devolver el token, y por eso el build falla:

const malos = [];
// ...por cada archivo, por cada token:
const resuelto = resolveUfToken(expr);
if (resuelto === null) malos.push(`${archivo}: token inválido ${match}`);

if (malos.length) {
  throw new Error(`Tokens inválidos: ${malos.length}.`);
}

Y después, una segunda pasada sobre el HTML ya escrito, que es cinturón y tiradores a propósito:

// GUARDIA: que no quede NINGÚN token sin resolver en lo que se sirve
const quedaron = archivosDeSalida.filter((f) => leer(f).includes('{{uf:'));
if (quedaron.length) {
  throw new Error(`Quedaron tokens sin resolver en: ${quedaron.join(', ')}`);
}

Esa segunda pasada parece redundante y no lo es. La primera valida los tokens que encontró. La segunda valida el artefacto que se va a servir, que es lo único que le llega al usuario. Si mañana alguien agrega otra fuente de contenido que no pasa por el mismo pipeline, la primera no la ve y la segunda sí.

La regla, dicha corta: si el dato es público y verificable, un deploy con el dato roto es peor que un deploy que no sale. Que se caiga el build.

Capa 4: que no dependa del deploy

Con todo lo anterior, actualizar la UF todavía requiere que alguien edite el archivo y haga push. Es rápido, pero es una persona en el camino crítico de un dato que cambia solo.

Así que arriba de eso hay una capa viva. Un scraper propio lee los valores oficiales y los deja disponibles en una API interna. El sitio la consulta y sincroniza el valor en el cliente:

Los valores del archivo son el piso: lo que ve el crawler, lo que se pinta en el primer render, lo que queda si todo lo demás falla.
La API es el techo: si responde, el visitante ve el valor de hoy sin esperar un deploy.

La respuesta se cachea, con TTL, en el borde. Y la degradación es lo único que hay que pensar bien:

const pba = Number(data?.pba);
const caba = Number(data?.caba);
if (!(pba > 0) || !(caba > 0)) return error(502);  // dato raro: no lo propagues

Ese chequeo es más importante de lo que parece. Un 0, un null o un string que se cuela desde arriba no rompe nada visiblemente: publica un monto equivocado, que es el peor resultado posible. Es más seguro no actualizar que actualizar con basura. Si la validación no pasa, el sitio se queda con el valor del archivo y nadie se entera.

Sumado, el orden de confianza queda: valor vivo validado, después valor del archivo, después nada. Nunca se llega a "nada".

Lo que me llevo

Un dato que cambia solo no puede vivir en el lugar donde se muestra. No es una cuestión de prolijidad: la actualización manual falla parcialmente, y fallar parcialmente es peor que fallar entero, porque te deja el sitio contradiciéndose consigo mismo.
El sistema de reemplazo necesita un guard que rompa el build. Sin eso cambiaste "dato viejo" por "token crudo".
Validá el dato vivo antes de mostrarlo. Un valor inválido que se propaga es peor que una actualización que no ocurre.
El fallback tiene que ser un valor real, no un vacío. Si la API se cae, la página sigue diciendo un número correcto de hace un bimestre en vez de un guion.

Nada de esto es sofisticado. Es un archivo, un reemplazo en build y dos excepciones. Pero convirtió "actualizar la UF" de una tarea de trece pasos que salía mal en una de dos números que no puede salir mal en silencio.

Los valores, por si llegaste buscando el dato

Bimestre	UF Provincia de Buenos Aires
Mayo-junio 2026	$2.215
Julio-agosto 2026	$2.271
Septiembre-octubre 2026	$2.281

En CABA la UF vale $949,99 y se ajusta por semestre, así que no acompaña estos movimientos.

Con la UF a $2.281, una infracción de 300 UF (cruzar el semáforo en rojo, VTV vencida) sale $684.300, y el tope de 1.000 UF llega a $2.281.000.

El desglose completo, con los montos por tipo de infracción, está en la nota del aumento de septiembre.
Si querés entender la Unidad Fija desde cero, qué es la UF y cómo se calcula lo explica con el histórico, y hay una calculadora de UF a pesos.
Todo esto sale de Multita, que consulta infracciones en 32 jurisdicciones argentinas por patente, DNI o CUIT. Si lo tuyo es integrarlo, la API devuelve las actas en JSON con el monto ya convertido a pesos al valor vigente, que es precisamente el problema que este post describe, resuelto del lado del servidor.

Si tenés un dato oficial de esos que cambian cada tanto y hoy vive en varios lugares de tu repo, el patrón es portable y se implementa en una tarde. La parte que no hay que saltearse es la tercera.

La unidad de cobro es una decisión de arquitectura, no de pricing

Multita — Tue, 25 Aug 2026 02:23:03 +0000

La unidad de cobro de un SaaS que scrapea no es una decisión de pricing. Es una decisión de arquitectura, y se toma antes de escribir el primer scraper, porque después condiciona todo: el caché, los reintentos, el modo asincrónico y hasta el contrato de errores.

Multita consulta infracciones de tránsito en 32 jurisdicciones argentinas (Provincia de Buenos Aires, CABA, provinciales y municipales). Cada una es un portal de gobierno distinto, con su HTML, su captcha y sus caídas. Este es el razonamiento detrás de cómo quedó definida la unidad, y qué obligó a construir.

El problema: N fuentes por consulta, y N es variable

Una consulta por patente puede tocar una jurisdicción o las 32. Hay dos formas obvias de cobrarla, y las dos son malas.

Cobrar por fuente consultada. El precio sube justo cuando el caso es más grande. Para el que integra, el costo se vuelve imposible de presupuestar: no sabe cuánto va a salir una consulta hasta después de hacerla. Y aparece un incentivo horrible, que es pedir menos fuentes de las necesarias para ahorrar, o sea empeorar el dato a propósito.

Cobrar por llamada, sin más. Suena simple hasta que aparecen los reintentos. Si un portal se cae y el sistema reintenta cinco veces, ¿quién paga esos cinco intentos? Si los paga el cliente, está pagando por la inestabilidad de un tercero. Si los paga el proveedor sin haberlo pensado, el margen se lo come la fuente más inestable.

La decisión fue: una llamada cuenta 1, sin importar cuántas jurisdicciones toque ni cuántos reintentos internos haga. Simple de explicar y de presupuestar. Pero esa promesa hay que sostenerla en el código, y ahí es donde se pone interesante.

Lo que esa promesa obliga a construir

1. Un caché que no se cobre

Si el precio es por llamada, el caché deja de ser una optimización y pasa a ser parte del modelo de negocio. En este caso el TTL es de 48 horas y el caché está aislado por organización, no global.

Lo del aislamiento no es un detalle. Son datos de deuda asociados a una patente o a un documento: dos cuentas distintas no pueden compartir nada. Dentro de una misma organización sí se comparte, y ahí el caché rinde de verdad, porque el panel web y la API comparten el mismo: una consulta desde la web deja el dato listo para el bot, y al revés.

La otra mitad es que el cliente sepa qué está recibiendo. Toda respuesta trae el estado del caché:

"cache": {
  "cacheado": true,
  "antiguedad_segundos": 420,
  "antiguedad_texto": "hace 7 min"
}

Con eso, la integración decide sola si le alcanza el dato de hace un rato o si necesita force_refresh: true. Para deuda vencida el dato de ayer sirve perfecto, no cambia minuto a minuto. Para reflejar un pago recién hecho, no.

Un caché sin esa transparencia es una mentira silenciosa. Con ella es una feature.

2. Reintentos que no empeoren el resultado

Cada jurisdicción se reintenta hasta cinco veces, cada intento por una IP distinta de un pool rotativo y, en las que tienen captcha, resolviendo uno nuevo. Todo eso sigue contando como una sola consulta.

Además, cuando una consulta queda incompleta y sobra tiempo dentro del presupuesto del endpoint, se reconsultan solo las jurisdicciones que fallaron. Las que ya salieron bien se leen del caché recién escrito, así que el reintento solo paga el costo de las fallidas.

La regla que hace que esto sea seguro es la que más costó escribir: el reintento se adopta solo si resolvió al menos una jurisdicción y no rompió ninguna que ya estaba bien. Si no mejora, se conserva la respuesta original tal cual. Un reintento que puede empeorar el resultado no es resiliencia, es una lotería.

3. Un camino asincrónico, porque el sincrónico no da

Acá va el dato incómodo, que conviene decir antes de que lo descubra el que integra: una consulta a todas las jurisdicciones sin caché espera a la más lenta. Puede tardar de segundos a un par de minutos.

Ningún chat aguanta eso en una sola request. Así que el camino recomendado para un bot es encolar y avisar:

POST /consulta/async  ->  202 { "job_id": "9f3a1c8e...", "poll_url": "..." }

El cliente responde "estamos consultando" al instante, y cuando el job termina llega un webhook firmado con HMAC (o se pollea el job_id). El campo resultado tiene exactamente la misma forma que la respuesta sincrónica, así que el código que parsea es uno solo.

Decir el peor caso en la documentación es más barato que un ticket de soporte por timeout.

4. Idempotencia, porque los clientes reintentan

Si se cobra por llamada, un reintento del lado del cliente por un timeout de red no puede contar dos veces. Un header opcional alcanza:

Idempotency-Key: <valor único por consulta>

Con eso, el reintento devuelve la respuesta original en vez de disparar una consulta nueva. Es de las cosas más baratas de implementar y de las que más discusiones de facturación evita.

El contrato que sostiene todo lo demás

Nada de lo anterior sirve si el dato no es confiable, y en un producto que agrega fuentes ajenas el riesgo más caro no es el error: es el falso vacío.

Si un portal de gobierno se cae y el sistema devuelve una lista vacía, el que integra la lee como "este auto no debe nada". Es el peor error posible, porque es silencioso y se propaga hasta el cliente final.

Por eso el contrato separa las dos cosas de forma explícita:

{
  "consulta_completa": false,
  "resultados": [
    { "jurisdiccion": "pba",  "ok": true,  "cantidad_actas": 2, "total_oficial": 142000 },
    { "jurisdiccion": "caba", "ok": false, "error": "timeout" }
  ]
}

ok: false significa "no pudimos ver", nunca "no debe". Y consulta_completa es el campo que hay que leer antes de afirmarle a una persona que no tiene deuda. Una jurisdicción caída no es un error HTTP: viene dentro de un 200, en su propio bloque.

Vale la pena la variante fea: hay dos municipios cuyo portal, buscando por documento y sin registros, responde un HTTP 500 en vez de una respuesta vacía. En la realidad operativa ese 500 significa "sin deuda". Se normaliza a cero actas con ok: true, pero solo para esas dos jurisdicciones y solo por documento. Cualquier otro error sigue siendo una falla real. Las normalizaciones de este tipo hay que acotarlas con nombre y apellido, o se convierten en el bug que devuelve falsos negativos en producción.

Lo que se gana cuando la unidad de cobro está bien elegida

Con la unidad definida así, el producto pudo crecer sin rediseñar el modelo. Sobre la misma llamada se apoyaron cosas bastante distintas entre sí: un modo que además de la deuda oficial devuelve el presupuesto ya calculado con el pricing de cada cliente y el PDF con su marca, monitoreo automático de listas de patentes que avisa cuando aparece una multa nueva o cambia el estado de un acta, y generación de recibos y de escritos de descargo.

Ninguna de esas features tuvo que inventar su propia unidad de cobro. Es el beneficio real de haberla decidido temprano: una consulta sigue siendo una consulta, sin importar cuánto producto se le apile encima. La contracara de la decisión, y conviene nombrarla, es que el proveedor absorbe la varianza: si mañana un portal se vuelve tres veces más lento, el costo lo come el proveedor, no el cliente. Ese es exactamente el riesgo que se está vendiendo.

El razonamiento de negocio detrás de todo esto, con la cuenta en horas y en plata, está contado aparte en cuánto le cuesta a una gestoría cotizar un caso.

Si vas a integrar algo parecido

Tres cosas que conviene dejar cerradas antes del primer scraper:

Definí la unidad de cobro primero. Condiciona el caché, los reintentos y el modo asincrónico. Cambiarla después es cambiar el producto.
Hacé explícita la diferencia entre "no hay" y "no pude ver". Es un campo en el JSON y te ahorra el peor tipo de bug.
Documentá el peor caso de latencia. El que integra lo va a encontrar igual; mejor que lo encuentre leyendo.

El contrato completo está en la especificación OpenAPI, y hay una versión en texto plano pensada para pasarle a un asistente en llms-full.txt. La documentación de la API de consulta y cotización tiene los ejemplos completos.

Entity SEO: how sameAs, Wikidata and Crunchbase tell Google your brand is real

Multita — Mon, 10 Aug 2026 12:00:00 +0000

Most SEO advice is about links and keywords. There is a quieter layer that matters more for a young brand: entity SEO, the job of convincing Google (and the AI models reading the same graph) that your brand is one real, identifiable thing. Here is what actually moved the needle for Multita.

sameAs is not a backlink

The common confusion: people think linking out to their own profiles drains authority. sameAs is not that. It lives in your structured data and it is an identity statement, not a vote. It says "these profiles and this domain are the same entity". It passes no PageRank and it costs you nothing.

"sameAs": [
  "https://www.linkedin.com/company/multita/",
  "https://www.crunchbase.com/organization/multita",
  "https://www.wikidata.org/wiki/Q..."
]

Wikidata and Crunchbase: the graph the models read

A Wikidata item and a Crunchbase profile are not big traffic sources. Their value is being structured, trusted nodes about your entity, the kind that get pulled into the Knowledge Graph that Google and AI assistants consult. For a new company with no Wikipedia page yet, they are the most credible "this exists" signal you can plant.

Why it matters for AI answers

When someone asks an assistant about your category, the model names you correctly only if your entity is well defined across these sources. Vague entity, vague or wrong citation. A consistent name, URL and description repeated across your structured data, your Wikidata item and your profiles is what makes the answer land on you.

Entity SEO will not rank a page by itself. It makes everything else you do attach to a brand the machines actually recognize, and for a new site that recognition is worth more than another handful of links.

Getting a brand-new site read by Google and AI: IndexNow, llms.txt and structured data

Multita — Mon, 03 Aug 2026 12:00:00 +0000

A new domain has no authority and no crawl history, so the default is to wait weeks for Google to notice you. You can skip a lot of that wait. When we launched Multita, three cheap and boring pieces did most of the work of getting indexed and getting quoted by AI assistants.

IndexNow: stop waiting for the crawler

IndexNow lets you ping search engines the moment a page changes, instead of waiting to be crawled. You drop a key file at your root and POST the changed URLs. On Cloudflare it is a few lines in a Worker. New pages got picked up in hours, not days.

llms.txt: a map for the models

llms.txt is a plain text file at your root that points AI crawlers at your most useful pages, in clean markdown. It is young as conventions go, but it costs nothing and it tells a model "this is what the site is about" without making it fight your nav and footer to find out.

Structured data: say what you are in a language machines trust

JSON-LD is the part both Google and the models lean on. An Organization and a WebSite block state your name, your URL and what you do, as data instead of guesswork.

<script type="application/ld+json">
{ "@context":"https://schema.org", "@type":"Organization",
  "name":"Multita", "url":"https://multita.com.ar" }
</script>

The payoff is clearer entity recognition, a real shot at a brand panel, and a much higher chance that an AI answer cites you correctly instead of inventing something.

None of this buys authority. It buys legibility, which for a new site is the thing standing between you and being found. Ship all three on launch day.

API design: raw data, or totals with the business logic baked in?

Multita — Mon, 27 Jul 2026 12:00:00 +0000

When you expose a data API you hit this fork fast: do you return raw, normalized records and let the client do the math, or do you return totals with your business logic already applied? We faced it building the API for Multita, which returns the traffic fines on a vehicle, and the answer that held up was "both, on purpose".

The case for raw

Raw, normalized records are honest. Each fine comes back with its amount, status and jurisdiction, and the integrator decides what to do with them. A developer building a dashboard wants exactly this. They have their own rules, and a pre-chewed total just gets in the way.

{
  "items": [
    { "jurisdiction": "pba", "status": "debt", "amount": 209250 },
    { "jurisdiction": "pba", "status": "voluntary_payment", "amount": 104600 }
  ]
}

The case for baked-in totals

Now picture a different integrator: a WhatsApp bot that quotes a client in a single message. It does not want to reimplement your discount rules, your "which fines actually count" logic, or your rounding. It wants a number it can trust. If every integrator re-derives that number, they will all get it a little wrong, each in their own way.

Why we ship both

So the Multita API returns the normalized items plus an optional summary with the totals already computed. Raw for the people who want control, totals for the people who want an answer. The rule we follow is narrow: never force the client to reimplement business logic to get a correct number, and never hide the raw data either.

If you are designing an API, start from who integrates it. A team with its own logic and a bot that just wants the result are different customers, and you can serve both without picking a side.