Problem

Support teams for a fiscal-accounting ERP receive thousands of tickets with incomplete information and very domain-specific vocabulary. The system classifies them, asks for missing data, retrieves context from official guides and historical cases, and prepares a response or summary for the human advisor — reducing time-to-first-response and manual triage load.

My role

Sole backend developer (~325 of ~340 commits). I designed and built it end to end: API, LangGraph orchestration, RAG layer, anonymization, XLSX ingestion, review dashboard, observability, migrations and CI.

Technical decisions

• LangGraph state graph instead of linear chains: separates collection, classification, retrieval and finalization nodes, with conditional routing (follow-up vs. human escalation).
• Hybrid retrieval: dense in Qdrant + BM25 with per-application filter + Vertex AI reranker, with historical boost and adaptive threshold. Better recall for domains with very specific jargon.
• Shadow mode + incremental v2 curated dataset to iterate on prompts and models, measuring p85 without touching production.
• LiteLLM + Langfuse as a unified layer: switch between Gemini Flash, Flash Lite and OpenAI without touching graph nodes.
• Three-layer anonymization before the LLM to avoid exposing sensitive fiscal data to external providers.

What it shows

Taking an applied-AI system from zero to production alone — architecture, non-trivial RAG, observability, shadow-mode evaluation and deployment — while keeping the code testable and the domain (fiscal data, sensitive) under control.

Stack

Problem

Small and mid-sized businesses lose sales by not responding quickly on WhatsApp and Telegram. The platform gives them an AI assistant that takes orders, reservations and stock queries, and escalates to a human when needed — configurable from a dashboard without touching code.

My role

Sole developer end to end (~132 commits, single author). Microservice architecture, multi-tenant Postgres model, layered prompt pipeline, tool-calling, nightly self-evaluation, two interchangeable WhatsApp providers, and a React configuration dashboard.

Technical decisions

• Schema-per-tenant in Postgres (instead of tenant_id columns) for real data isolation and granular per-customer backups.
• Redis Streams as the bus between Gateway and Core, instead of direct HTTP, to decouple channels (Telegram/WhatsApp) from the AI engine and enable retries and backpressure.
• Layered prompt (IDENTITY → CAPABILITIES → INSTRUCTIONS → ADJUSTMENTS → KNOWLEDGE → HISTORY) with tools filtered by tenant capabilities in YAML, so the same core serves very different businesses without forks.
• Nightly self-improvement loop: a worker evaluates conversations with an LLM and proposes prompt adjustments per tenant, reviewable from the dashboard.

What it shows

Taking a full SaaS product from zero to a sellable MVP alone — distributed architecture, real multi-tenancy, LLM integration and ops dashboard — with isolation, decoupling and configurability decisions designed to scale across many customers.

Stack

Problem

Companies with hundreds of utility accounts (electricity, gas, water, telecom) spend thousands of hours per month downloading invoices from portals, validating them, posting them to ledgers and paying them. The platform automates that cycle end to end, with auditing, alerts and bank reconciliation built in.

My role

Backend lead / principal maintainer. Of ~9,700 total commits, ~7,100 are mine (over 70%). I designed the async worker subsystems, reporting, AI pipelines for bill extraction/digitization, bank reconciliation, alerts, and most of the Prisma schema. I coordinate a team of 4–6 developers.

Technical decisions

• BullMQ-based architecture with 79 specialized workers (download, audit, reconciliation, payments, alerts) to isolate failures per external integration and enable retries/backpressure without affecting the API.
• Custom AI layer with LangGraph agents, RAG and MongoDB memory, with LangSmith observability, for structured field extraction from heterogeneous invoices (PDF/image) and email classification.
• 147 Excel reports generated as jobs on disk under a uniform pattern, letting business users request complex extractions without touching BI.
• Postgres → BigQuery datastream for analytics without penalizing OLTP; partial indexes and custom SQL functions to speed up critical payment flows.

What it shows

Sustaining and evolving a long-lived critical system with many fragile integrations (external portals, banks, OCR/AI), prioritizing observability, decoupled queues and automation where manual work existed before. Comfortable crossing domains: DB performance, workers, applied AI, business reporting.

Stack