← Back to home

Open archive / 11 PROJECTS · 04 CATEGORIES

What I built, and why.

This is everything I shipped, prototyped or killed over the past few years. Some are alive. Some died along the way. I'm leaving them all because each one taught me something. This isn't a sales portfolio — it's my working notebook.

/ Vertical SaaS

03 products

Custom software for specific industries. Build → deploy → direct customer support.

2025
  • SHIPPED
  • WIP

Sesión

Practice management SaaS for independent psychologists. Built in 5 days during the Kaszek × Anthropic hackathon 2025.

↳ 200/3000 builders · 5 days · $0.14 per patient

  • SvelteKit
  • NestJS
  • PostgreSQL
  • Prisma
  • Tailwind
  • Claude Sonnet
  • Claude Opus

/ Why I built it

My therapist told me she was spending 3 hours a week loading appointments, invoices and notes into four different tools. I saw a mature vertical with no decent Argentine SaaS — the ones that exist are expensive or rotten inside. When the Kaszek × Anthropic hackathon opened applications it was the excuse: 5 days, real deadline, now or never.

/ Technical decisions

  1. 01
    SvelteKit over Next

    I needed to ship full UI in 48 hours without ceremonies. Svelte's learning curve is dramatically shorter than Next + React Server Components. For a single dev against the clock, the decision was obvious.

  2. 02
    PostgreSQL + Prisma

    I know this stack. I couldn't afford debugging Mongo aggregations at 3 AM on day 4. Prisma gave me versioned migrations and type-safety without thinking.

  3. 03
    Claude Sonnet to execute, Opus to advise

    Sonnet generates the automatic post-call session summary (~1500 tokens, $0.14 per patient/month). Opus only kicks in when the family requests a quarterly report or a clinically complex case shows up. Cheap-by-default, expensive-when-needed pattern.

  4. 04
    Magic link auth, no social OAuth

    Psychologists don't want cross-app Google/Facebook tracking inside the tool where they store clinical notes. Email + magic link was the right call even though it added onboarding friction.

/ What I learned

  • Building solo is 3x faster than working with a team when the problem fits in one head. Communication has non-trivial cost.
  • Hackathons are worth it: they give you deadline, social validation and a first customer (yourself) on the same plate.
  • The most-used feature (SMS appointment reminders to patients) I added the last night out of boredom. Lesson: throw in marginal ideas if you have 2 spare hours — sometimes they're the ones that move the product.
2024
  • SHIPPED
  • REVENUE

LocalCenter

B2B vertical SaaS for Argentine wholesale merchants. 9 paying customers, 1 year in production, full AFIP integration (WSAA + WSFE).

↳ 9 customers · 1 year in prod · AFIP WSAA + WSFE

  • Angular 17
  • NestJS
  • SQL Server
  • AFIP WSAA
  • AFIP WSFE
  • Tailwind
  • Angular Material

/ Why I built it

My dad ran a wholesale business and every system he tried either charged $200k ARS/month or was rotten inside (2008 UI, no API, email support with three-day replies). I built him one. Then I told him «this can be sold» — and we started selling it by word of mouth. Today there are 9 paying customers and I'm the only developer, support and customer success.

/ Technical decisions

  1. 01
    SQL Server over Postgres

    My dad's customers already used Excel + Office and lived in the Microsoft ecosystem. Reducing cultural friction mattered more than the «best stack». When a customer needs an export, it goes straight to .xlsx without conversion.

  2. 02
    Angular 17 with Material

    I had reusable Angular Material components from another project. Speed-to-start weighed more than framework purity. In 2 weeks I had product, customer, invoice and stock CRUD working.

  3. 03
    AFIP: Redis queue with exponential retry

    The AFIP integration (WSAA + WSFE) is the most painful part of the product. Access tokens that expire every 12 hours, aggressive rate limits (3 req/s), undocumented 8001 errors. Solution: Redis queue that stores each pending invoice and retries with exponential backoff. If AFIP is down, the customer invoices anyway and the system syncs when it's back.

  4. 04
    Self-hosted on an Argentine VPS

    AWS would have been more expensive and slower for my customers. The Buenos Aires VPS gives <30ms latency for everyone. Argentine compliance is also simpler (data doesn't leave the country).

  5. 05
    Direct support, I handle the tickets

    No tier 1, no chatbot. I get more insight from a 15-minute call with a real customer than from 100 surveys. 70% of last year's features came from problems I saw in support.

/ What I learned

  • Selling what you already built is 10x easier than selling what you're going to build. Having the first customer (my dad) locked in killed all the validation pressure.
  • Argentine customers want WhatsApp, not web chat. Learned after 6 months of total silence in my web chat support — the day I turned on WhatsApp Business, I got 12 messages in the first hour.
  • A boring vertical (electronics wholesale) with high margin and low churn beats a sexy vertical (B2C AI startup) with vanity metrics and 8% monthly churn. Wholesalers don't switch systems easily.
2026
  • SHIPPED

balanza-agent

Desktop app (Tauri, Rust + JS) that connects Kretz scales to the LocalCenter system. v1.1.4 in production. Companion to the main product.

  • Tauri 2
  • Rust
  • TypeScript
  • Kretz protocol
See detail

/ Why I built it

My LocalCenter customers sell by weight (cables, rods, electrical materials). Each Kretz scale has its own serial protocol. Without integration, the operator reads the scale by eye and types the number by hand — guaranteed human error. balanza-agent reads the scale via USB and sends the weight to the system without touching the keyboard.

/ Technical decisions

  1. 01
    Tauri over Electron

    Electron weighed 200MB and customers run old Windows machines. Tauri weighs 12MB and opens instantly. For a companion app that doesn't need a browser engine, it was obvious.

  2. 02
    Kretz protocol documented by hand

    Kretz doesn't publish specs. I reverse-engineered it with a USB oscilloscope and two hours of patience. I documented the protocol in kretz-protocol/ in case someone else needs it.

/ What I learned

  • Hardware integration is 80% patience + 20% code. The day the scale «didn't respond» it was a broken USB cable.
  • Companion apps are a wildly undervalued way to extend a SaaS. For customers, balanza-agent is worth as much as the entire main app.

/ AI Systems / Agents

04 systems

Autonomous agents that get work done. Orchestration, RAG, multi-agent.

2024 — present
  • WIP
  • LAB

JARVIS

Multi-machine system to orchestrate Claude Code agents across my local setup. Four machines, four accounts, one brain.

  • Bash
  • Node.js
  • tmux
  • SSH
  • Tailscale
  • Claude Code SDK
  • +1
See detail

/ Why I built it

When I started using Claude Code seriously I realized I filled the context window of a single account in a day. The obvious solution (pay more) didn't solve the real bottleneck: I couldn't think about four problems simultaneously. JARVIS is the system that spawns four parallel agents, each with its own account, attacking different parts of the same problem, and syncs them at the end of each round.

/ Technical decisions

  1. 01
    Tailscale as mesh VPN

    The four machines live in different networks (home, office, mobile). Setting up OpenVPN or WireGuard manually was the first thing I tried — I lost 2 days. Tailscale solved everything in 15 minutes. Lesson: use the right tool when it exists.

  2. 02
    tmux as UI

    I didn't want to build a web frontend when a 4-pane tmux grid already does the job. Each pane = one machine + agent. tmux status bar shows load, latency and active account. No polish, full information density.

  3. 03
    Bash + Node for orchestration

    Python would have been cleaner but less portable (NOMAD is Windows with WSL). Bash + node is the lowest common denominator. All the parallelization logic lives in ~/jarvis-parallel.sh, 200 lines of bash I know by heart.

  4. 04
    Fixed roles per machine

    ATLAS (Mac Mini M4 Pro) = orchestrator. NOVA (i5 + RTX 3060, Windows) = Node backend. PIXEL (Ryzen + RTX 3070, Pop!_OS) = frontend + GPU heavy. NOMAD (Ryzen 7 laptop) = mobile + backup. Each machine contributes what it does best, the orchestrator does the matchmaking.

/ What I learned

  • Tools you build for yourself are the ones you understand best. If I ever productize JARVIS, it'll be with knowledge of real usage, not market specs.
  • SSH stdin keepalive is a world of its own. I learned more bash in two weeks of JARVIS than in five years of programming. When a system fails silently, that's where you learn the most.
  • The context window is a real bottleneck, not invented. People using Claude Code 10hrs/day will reach this conclusion on their own. A cleaned-up version of JARVIS could be a product, but it's still very mine.
2026
  • WIP

Agentingk

Multi-tenant conversational AI operators on WhatsApp. Multi-line, anti-ban, human handover, failover to official WABA. Replaces call-center operators.

  • TypeScript
  • Turborepo
  • Fastify 5
  • Next.js 15
  • Postgres + pgvector
  • Redis + BullMQ
  • +4
See detail

/ Why I built it

Most Argentine companies that sell through WhatsApp do it with human operators sitting in front of Chrome all day. Cost is high, turnover is brutal, quality is uneven. What AI does well today (standard queries, lead qualification, product info) covers a big chunk of the work. Agentingk targets that work and leaves the rest to the human via handover.

/ Technical decisions

  1. 01
    Monorepo with strict apps + packages

    Turborepo with three apps (Next 15 dashboard, Fastify orchestrator, Node worker) and seven packages (ai-engine, rag, wa-providers, human-emulation, db, config, shared). Strict TypeScript with exactOptionalPropertyTypes and noUncheckedIndexedAccess. That's the rigor level required when the system has to run 24/7.

  2. 02
    Adapter pattern for WhatsApp providers

    BaileysProvider by default (free), OpenWAProvider as alternative, WhatsAppBusinessAPIProvider for official failover. If Meta kills a number, the system migrates itself to the official channel. It's the only way to operate with confidence next to a channel hostile to automation.

  3. 03
    LLM router cascade by cost

    Groq Llama 3.3 as default ($0.05/M tokens). Claude Haiku for queries that need longer context. Sonnet only on critical triggers (escalation, big leads, complaints). Cost-per-message matters when you handle thousands of simultaneous chats.

  4. 04
    Explicit human emulation

    Package human-emulation with gaussian delays, typing indicators, message splits and warm-up limits. WhatsApp bans accounts that behave «too well». The AI has to write like a tired human, not perfect GPT-4.

/ What I learned

  • Operating on hostile channels (Baileys + unofficial WhatsApp) is a constant war. The WABA failover isn't optional — it's the mandatory plan B.
  • Multi-tenant is 4x harder than single-tenant. Each customer has its own KB, lines, operators, prompts. Without good isolation, one bug breaks everything.
  • Hybrid RAG (vector + tsvector) beats pure vector for Argentine Spanish. Queries like «how much is the 1/2 chrome pipe» mix substring matching with embeddings.
2026
  • IDEA
  • LAB

Mendr

The bug enters Sentry → leaves as a pull request. Production-bug auto-fix with Claude SDK. 5 autonomy levels: from comment to direct hotfix push.

  • Claude Agent SDK
  • Next.js
  • Redis + BullMQ
  • GitHub API
  • Sentry webhook
See detail

/ Why I built it

Every team has an on-call who wakes up at 3 AM for bugs that could be fixed with 10 lines of code. 70% are regression bugs that the agent can diagnose better than a sleepy human. Mendr is the idea: your on-call's first line of defense is an AI.

/ Technical decisions

  1. 01
    5 autonomy levels as contract

    Level 0: comment on Sentry. Level 1: PR draft. Level 2: PR + green tests. Level 3: PR auto-merge if low risk. Level 4: direct push to hotfix branch. The team picks the level per repo. Trust is earned, not assumed.

  2. 02
    Claude Agent SDK as runtime

    The agent clones the repo, reads the stack trace, identifies the culprit file, proposes a fix and runs the tests. Sandbox per tenant. No output streamed to the client — the agent works silently and delivers the result.

/ What I learned

  • The idea was born watching recurring AFIP errors in LocalCenter — the same bug patterns happening overnight and resolving in 10 minutes the next morning. If an agent can see the pattern, it should be able to propose the fix.
  • Ideas you build for yourself are the ones you understand best. Mendr was born from my frustration operating products, not from a pitch deck.
2026
  • LAB
  • OPEN SOURCE

lightrag-mcp

MCP server for LightRAG. Connects Claude Code to a unified knowledge graph + vector store. Python 3.13, voyage AI embeddings, Anthropic API.

  • Python 3.13
  • LightRAG
  • MCP
  • voyageai
  • Anthropic
See detail

/ Why I built it

LightRAG is graph-based RAG that combines knowledge graph + dense retrieval. It beats pure-vector for multi-hop queries. I wanted to use it from Claude Code without standing up a custom HTTP server — MCP is the right channel.

/ Technical decisions

  1. 01
    MCP as adapter layer

    MCP standardizes the contract between the agent and the data source. Any MCP client (Claude Code, Cline, Zed) can use this server. Reuse > custom.

/ What I learned

  • Open protocols like MCP cut work. If a protocol exists and works, the cost of adopting it is always worth it.

/ Quantitative Trading

02 systems

Quant systems on prediction markets. Multi-strategy, defensive safeguards.

2026
  • SHIPPED
  • WIP

atlas-fleet

Fleet of 13 Marvel-named trading bots on Polymarket. Multi-strategy: weather ensemble, bonds, market making, whale-copy, contrarian, Polymarket vs Kalshi arbitrage. V2.0 with circuit breakers, atomic state and heartbeats.

↳ 13 bots · Avellaneda-Stoikov MM · circuit breakers · v2.0

  • Node.js
  • Polymarket CLOB
  • WebSocket
  • Claude
  • Telegram
  • Docker
  • PM2
See detail

/ Why I built it

Prediction markets are one of the few places where a retail trader can build edge if they do the work. Polymarket in particular has liquid books, low fees and a huge information surface that big houses don't watch. What started as a 200-line script became a fleet of specialized bots — each with a clear role — because solving «prediction + execution + risk + arbitrage» with a single agent is bad engineering.

/ Technical decisions

  1. 01
    Marvel naming + fixed roles

    Each bot has a Marvel name and a unique role. TONY orchestrates. JARVIS scans news (RSS, Reddit, Twitter, CoinGecko). FRIDAY watches WebSocket prices + whales. VISION learns and generates wisdom. XAVIER coaches each bot. STEVE runs weather ensemble (GFS/ICON/ECMWF). REED plays bonds (buys near-certain at 93-99c). QUILL does market making with Avellaneda-Stoikov. STRANGE arbitrages Polymarket vs Kalshi. The names aren't cosmetic — they force me to separate responsibilities.

  2. 02
    RiskManager with atomic state

    Drawdown limits, position correlation, per-domain circuit breakers (CLOSED → OPEN → HALF_OPEN like Hystrix). RiskManager is the only way to touch capital. If the machine dies mid-trade, write→verify→rename guarantees no inconsistent state.

  3. 03
    Heartbeat + preflight

    Each bot sends heartbeat to the orchestrator. If one dies, TONY restarts it. Before any launch, preflight validates env vars, disk space, network, dependencies. Lesson from building this: a system that doesn't self-kill dies dirty.

  4. 04
    Telegram for all monitoring

    Zero dashboard at first. Just a Telegram bot (@atlas_fleet_lauti_bot) that pings critical events: fills, drawdowns, circuit-breaks. Much more efficient than opening 5 tabs at 3 AM when something is on fire.

/ What I learned

  • Separating bots by unique role is 5x easier to reason about than a super-agent. The rule: if two bots talk to each other a lot, they're probably the same one.
  • Defensive programming isn't optional when real money is at stake. Atomic state, circuit breakers and preflight aren't overhead — they're the only reasons the system runs unsupervised.
  • Names matter. The day I renamed PEPPER (Arg stocks / MERVAL) I finally understood its role. Before, it was «the Argentine market bot» and never quite clicked.
2026
  • WIP

atlas-fleet-nautilus

Port of atlas-fleet to NautilusTrader (Python). 1935 tests, 81.63% coverage, mypy clean, ruff clean. 3 active strategies, 5 production-grade safeguards.

  • Python 3.13
  • NautilusTrader
  • uv
  • pytest
  • mypy
  • +1
See detail

/ Why I built it

JS is fine for prototyping but NautilusTrader is the only serious open-source platform for event-driven trading. Full type safety, deterministic backtest, paper/live with the same codebase. Porting atlas-fleet to NautilusTrader is the next step to make the system defensible.

/ Technical decisions

  1. 01
    5 defense-in-depth safeguards

    Wallet spend caps, circuit breaker, pre-submit simulation, deadline enforcement, isolated private-key handling. Live mode is behind a flag and dormant until the operator signs kernel-validation.

  2. 02
    Coverage as contract

    1935 tests aren't ego — they're the only way to migrate without destroying the legacy. Each JS strategy has a golden test that matches outputs before/after. If I break something, I know exactly what.

/ What I learned

  • Porting is 3x harder than building. Every old decision has a reason you discover mid-port.
  • The test suite is the most expensive and the most valuable thing. Without it, I wouldn't dare touch anything.

/ R&D Tools

02 experiments

Experiments, design tools, computer vision. What I prototype when there's no client.

2026
  • IDEA
  • WIP

Lume

«Design websites like Canva. Ship code like a senior.» Multi-Modal Generative Web Design (MMGD). Conversation with AI + visual edit → clean Astro/Next + Tailwind code.

↳ Full PRD · 7 docs · Next.js prototype

  • Next.js
  • Astro
  • Tailwind v4
  • Claude / GPT
  • TipTap-like editor
See detail

/ Why I built it

Today the non-technical user who wants a website is stuck between two bad options: Webflow/Canva (limited output, lock-in) or hire a dev (slow, expensive). «No-code» tools never generate code a human wants to touch. Lume targets the middle: you describe in Spanish what you want, the AI proposes, you edit visually, and you walk away with a Git repo a dev can maintain.

/ Technical decisions

  1. 01
    MMGD: custom methodology

    Multi-Modal Generative Web Design separates intent (what you want) from form (how it looks) and emits three outputs: design tokens, Astro/Next components, and a reusable PRD. That separation is what allows the code to be clean instead of LLM-generated gobbledygook.

  2. 02
    Output target: Astro/Next + Tailwind

    Not static HTML, not «export to Wix». Real repos with package.json, CI/CD ready, deploy to Vercel/Netlify. If the AI doesn't generate code you'd touch, it's noise.

  3. 03
    Visual editor over the AST, not the DOM

    When the user drags a component, it edits the Astro AST and regenerates the code. No inline CSS injected. The result is code that looks human-written.

/ What I learned

  • Writing the whole PRD before typing a single line of code hurts but saves months. I already know which problems are MVP and which are v2.
  • Custom methodologies (MMGD) are a thinking tool, not marketing. They help me defend decisions when the pressure to «do what Framer does» shows up.
2026
  • LAB

fb-marketplace-search

FB Marketplace scraping + visual ranking with local CLIP embeddings (MPS / CUDA / CPU). You search «rubber membrane» and it sorts listings by visual similarity against an image of yours.

  • Python
  • Apify
  • CLIP
  • FastAPI
  • Vite
  • +2
See detail

/ Why I built it

Searching for specific materials on FB Marketplace is horrible: the algorithm shows you tangential stuff, titles lie, you can't filter by «looks like this». I built it because I needed to find exactly one rubber membrane and FB returned tires. Five hours later it worked.

/ Technical decisions

  1. 01
    Local CLIP instead of API

    OpenAI embeddings cost money and are slow over the network. CLIP runs locally on Apple Silicon (MPS) in 200ms per image. Once embeddings are computed, ranking is pure cosine.

/ What I learned

  • Tools you build to solve your own problem are the ones you finish best. I had no client, just need.
  • CLIP is absurdly useful for almost any visual similarity task. If your product involves images, it should be in your stack.

How I think / PRINCIPLES

Five principles I apply.

These aren't axioms. They're things I learned by building, failing and killing projects. Each one came with a receipt.

  1. / 01

    Start with real data before UI.

    I designed screens for a full day before checking whether the API gave me the data I needed. It didn't. I had to redesign everything. Now: data and endpoints first, UI after.

    Sesión
  2. / 02

    Boring vertical > sexy vertical.

    Argentine wholesalers aren't pitch-deck material. But they pay on time, don't switch systems and a well-fixed bug earns you two years of loyalty. Learned with LocalCenter.

    LocalCenter
  3. / 03

    Build solo until you can't.

    When the problem fits in one head, the team is overhead. JARVIS works because it's just me deciding everything. I add people when the bottleneck is speed, not ego.

    JARVIS
  4. / 04

    Killing is harder than building.

    Each dead project cost me months. The signal to kill is never loud — it's absence: customer silence, no urge to touch the code, metrics you lie about in conversation. When you see it, kill.

  5. / 05

    Customers don't want features, they want the problem to go away.

    I added 12 Excel reports to LocalCenter that nobody used while the customer just wanted it to «stop throwing error 8001 when I invoice». An hour fixing that error moved more than three months of new features.

    LocalCenter

If any of this resonated, write to me.

Let's talk →