Skip to content
Ricardo Brossard

Open to remote roles

Ricardo Brossard

AI Engineer · Full Stack Developer

I build full-stack systems with AI and automation that ship to production and get used every day. Systems Engineer (UTN) working end to end: architecture, database, backend, frontend, integrations and deployment.

Projects

Systems I designed and built end to end, as the sole engineer.

Multi-merchant delivery, Argentina · Live in production

Zizu

The customer orders, the shop prepares, the courier delivers and the admin oversees everything, each with their own screen and the same order updating live.

Pantalla del cliente con la dirección de entrega, las categorías, una promoción de envío gratis y los comercios abiertos con su tiempo de entrega

The problem

In small cities, shops take orders by phone and WhatsApp, with no platform of their own to coordinate customer, shop and courier.

What I built

An app where the customer orders, the shop prepares, the courier delivers and the admin oversees everything, each with their own screen and the same order updating live. I built it solo from scratch, with Mercado Pago payments end to end (checkout, chargebacks, refunds and commissions) plus cash. The hardest part was the money: every payment is confirmed server-to-server and the payment ledger cannot be edited even with direct database access. Under the hood: one PostgreSQL database with role-based access on all 30 tables, order state rules enforced server-side, and atomic order assignment, so if two couriers tap "Take" at once, only one wins.

Results

  • 4 milestones delivered, audited and billed
  • Every change runs 152 end-to-end and 57 unit tests against a production-identical environment
  • 118 versioned migrations and role-based access on all 30 tables
  • Installable app (PWA) with automatic deploys

Stack

React 18ViteTypeScriptTailwind CSSTanStack QueryZustandLeafletPWA con WorkboxSupabasePostgreSQLRow Level SecurityRealtimeAuthStorageEdge Functions en Denopg_cronMercado PagoOpenStreetMapGoogle GeocodingResendPlaywrightnode:testGitHub ActionsVercel

Real estate agency in Buenos Aires · Live in production, 10 users

CRM Lexinton

Gathers inquiries from 6 channels, links each one to its property and assigns it to the right agent, with the team's WhatsApp built in.

Bandeja de WhatsApp del sistema, con las conversaciones del equipo separadas por tasaciones y ventas

The problem

Buyer and tenant inquiries arrived every day through listing portals, Facebook ads and the website, and ended up in a shared inbox. Each one depended on someone copying it by hand into a spreadsheet, and the owner could not tell how many came in, which were answered or who was handling each client.

What I built

A system that gathers every inquiry into one place with no manual entry: each one arrives linked to the property it is about and assigned to the right agent, and the team follows up from there, including the agency's WhatsApp. It connects to Tokko Broker, where the agency manages its listings, and mirrors its inventory (read-only). Every 15 minutes it reads the inbox, recognizes which portal each inquiry comes from, detects repeat contacts and links each one to its property by listing code or, failing that, by address. WhatsApp runs on Meta's official API: every conversation sticks to the client's record, and automated follow-ups stop as soon as the client replies. Visits are booked in each agent's Google Calendar. The backend is 100% TypeScript.

Results

  • 3,500+ inquiries captured with no manual entry
  • 98% of last month's portal inquiries linked to their property automatically
  • 6,805 audited status changes, 207 valuations and 186 visits booked
  • 7 automated flows, 100 unit tests and 33 end-to-end tests

Stack

Next.js 14ReactTypeScriptTailwind CSSSupabasePostgreSQLRow Level SecurityRealtimeEdge Functions en DenoWhatsApp Cloud APIGmail APIGoogle Calendar APITokko Broker APIVitestPlaywrightVercel

Own product for shops · Live, tomanota.lat

TomaNota

The assistant chats with the customer, builds the order with the real price list and drops it on a board for the shop to prepare.

Tablero de pedidos del comercio, con columnas para pedidos nuevos, en preparación, listos y en camino, y los botones para avanzar cada uno

The problem

The neighborhood pizzeria takes orders on WhatsApp while the owner is at the counter. At peak hours messages go unanswered and orders are jotted on paper, with mistakes.

What I built

An assistant that answers that WhatsApp on its own: it chats with the customer like a person would, builds the order with the menu's real prices, confirms it and drops it on a board for the shop to prepare, next to orders from the online menu with QR and from the counter. Under the hood, a language model (Vercel AI SDK over an OpenAI-compatible API) works with 8 tools, and none of them accepts a price: the model only picks catalog items and quantities, the server computes every total, and no order exists until the customer taps Confirm. Every message first passes fixed checks: per-chat ordering, duplicate discarding, auto-silence when the owner writes, and bot-loop cut-off, with a rules engine as fallback.

Results

  • 900+ automated tests and 13 full conversations stored as specification
  • Test bench against the real model with 1,203 simulated conversations
  • 8 tools for the model, none of which accepts a price
  • 46 tables with Row Level Security

Stack

React 18ViteTypeScriptTailwind CSSTanStack QueryPWALeafletNode.js 22FastifyVercel AI SDKAPI compatible con OpenAITool callingWhatsApp Cloud APIRedisSupabasePostgreSQLRow Level SecurityRealtimeFunciones plpgsqlVitestSuites SQLGitHub ActionsgitleaksDocker ComposeVercel

For a real estate agency in Buenos Aires · Tested end to end with real data, code published

Tasador

AI finds and reads comparable listings; the price comes from an explicit formula, never from the model. Full application, tested with real data.

Pantalla de fuentes de datos del Tasador: avisos descubiertos y nuevos de cada fuente, la última corrida de ingesta y la cobertura por barrio con el USD/m² promedio del corpus

The problem

To price a listing, an agent compares it by hand against similar listings, and two valuations of the same property can end up at different prices with no written reasoning.

What I built

A system that produces the valuation report in about a minute, with the comparable listings that justify the price. AI finds and reads similar listings and decides which ones are comparable, but the price comes from an explicit formula, never from the model, and every fact the AI extracts is checked against the original text. Under the hood: an 11-step LangGraph agent with a full RAG stack (embeddings, lexical search, fusion and reranking) evaluated on 113 queries before deciding: lexical search, the simplest option, won and is the one switched on. With fewer than 5 valid comparables, the system says it does not know.

Results

  • Report in about a minute, with the same criteria every time
  • Lexical search won the evaluation: nDCG@25 of 0.821 vs 0.747 for the baseline, on 113 queries
  • A figure check blocks numbers that are not in the data (made-up prices passing it went from 50.5% to 4.3%)
  • 492 backend tests and 55 Playwright end-to-end tests in CI, 2 to 5 US cents per report

Stack

Next.js 15React 19TypeScriptPython 3.12FastAPIPydantic v2LangGraphLiteLLMBúsqueda léxica en PostgreSQLpgvectorfastembedReciprocal Rank FusionPostgreSQL 16RedisSQLAlchemy 2Alembicpg_trgmpytestPlaywrightmypyGitHub ActionsDocker Compose

Stack

Frontend
ReactNext.jsTypeScriptViteTailwind CSSAstro
Backend and data
Node.jsFastifyPythonFastAPIPostgreSQLSupabaseRedis
Artificial intelligence
LangGraphRAGpgvectorTool callingVercel AI SDKLiteLLM
Integrations
WhatsApp Cloud APIMercado PagoGmail APIGoogle Calendar APIWebhooks
Quality and deployment
PlaywrightVitestpytestGitHub ActionsDockerVercelCloudflare

Looking for someone like this on your team?

Email me or reach out on LinkedIn. I reply within the day.