E Eduardo

Eduardo · Software engineer

I turn unclear software ideas
into working proof.

Right now that means a clinical analytics tool for a medical practice in Florida — turning weekly FHIR exports into a patient worklist clinicians actually trust. Before that: bilingual healthcare and small-business web systems, and an AI capstone I still think about.

Read the case files How I work
Bring me the thing before it is a clean ticket Messy input, clear model, working proof Explore broadly, build narrowly Smallest system that can teach something true Context into constraints

Case files

Projects where the problem mattered as much as the code.

I don't just write the code once the problem is defined — I help define the problem well enough that the code has somewhere meaningful to go. Lately that work keeps landing in healthcare and operational data.

Healthcare · 2025 — in progress Python · DuckDB · FHIR

Tuya Analytics Featured case file

A primary-care clinic needed a weekly list of the patients most at risk of falling through the cracks — and a way to justify every name on it to a clinician who would push back.

A local Python + DuckDB tool that ingests Practice Fusion Bulk FHIR exports and appointment reports, then runs a configurable rubric scoring engine over the whole patient panel. Versioned runs, component-level audit trails, and a CLI that can diff a new rubric against the old one before it ever reaches the UI.

  • FHIR Bulk export ingest into a single-file DuckDB warehouse
  • YAML-driven rubric — every score explains its own components
  • v1/v2 engines run in parallel for safe rubric migrations
  • Fully local — no PHI ever leaves the practice's machine

The clinic gets a defensible worklist every Monday — and can ask any score "why?" and get a real answer.

Read the case file
Healthcare · 2025 EN / ES · hand-written

Tuya PA tuyamedical.com

The clinic's front desk was fielding constant calls for things that belonged on the website — hours, addresses, intake forms, accepted insurance. The old template site wasn't answering them.

Full rewrite into hand-written HTML and CSS — no build step, no dependencies. Bilingual EN/ES with proper hreflang, a Patient Fusion OAuth callback, public JWKS, downloadable PDFs, and a sitemap. The whole site fits in one folder a non-engineer could edit.

  • Zero npm dependencies, zero build step
  • OAuth callback + JWKS for clinical integrations
  • Localized alternates and JSON-LD per language

Patients self-serve hours, locations, and forms — fewer avoidable calls to the front desk.

tuyamedical.com
Hospitality · 2025 EN / ES / PT · Astro 5

Taxi Wine Mendoza, AR

A single-driver wine tour needed a credible presence in three languages that routed serious inquiries straight to a phone — without paying a booking platform a cut of every trip.

A trilingual marketing site in Astro 5 + Tailwind v4. One typed config file drives services, routes, FAQs, and per-language JSON-LD. A floating WhatsApp action turns interest into a real conversation in one tap.

  • Three localized routes with proper hreflang
  • Single site.config.ts owns 99% of content
  • No third-party booking widget, no platform fees

Visitors land in their own language and book directly with the driver.

taxiwine.com
Applied AI · 2023 Capstone

Gompai CS capstone

Senior capstone: an AI chatbot robot with vision and per-person memory. The interesting problem wasn't the hardware — it was designing the brain.

We split the agent into two cooperating models — a fast one for reactive speech, a slower one for deliberation — over a semantic-meaning memory store the slow model retrieved from before responding. Patterns now standard in production LLM stacks; in 2023 we were sketching them from first principles.

  • Dual-model brain: reactive speech & slower thought
  • Embedding-based memory + retrieval before generation
  • Computer-vision module for person recognition

The first time I had to design a system before the off-the-shelf abstractions for it existed.

GitHub

How I work

A way of working you could actually hold me to.

Not principles I can hide behind — things I can be caught not doing. This is the part of the job I care about most: getting the shape right before the code piles up.

  1. 01

    Map the real workflow before writing code

    I sit with the actual messy version first — the spreadsheet, the phone calls, the step that keeps breaking — and name the real problem before proposing a system for it.

  2. 02

    Build the smallest version that answers the riskiest question

    The first artifact should test the thing most likely to be wrong, not decorate the thing already safe. A small working system teaches faster than a big speculative plan.

  3. 03

    Make the system explain its own decisions

    Why this score, why this recommendation, why this ranking. If a system can't show its reasoning, the people relying on it can't trust it — so I build the explanation in, not on.

  4. 04

    Leave code the next person can run without me

    Hand-written, documented, dependency-light. The next engineer — often me in three months — should read the code and the notes together and understand why each call was made.

4 projects across healthcare, web, and applied AI
3 languages shipped on a single marketing site
0 npm dependencies on tuyamedical.com
<90kB typical first-load page weight

About

Engineer by training, most useful in the figuring-out part.

My background is computer science, but my taste is closer to engineering science: observe the real system, form a model, test it, then build the smallest machine that proves it works.

Lately that's pulled me into healthcare and operational data — messy domains where the constraint nobody mentioned is usually the one that matters. I'm headed further in: a couple more clinical projects, and an applied-AI build outside the field, on the way.

I'm open to client work, embedded engagements, and the right full-time role. If something here resonates, I'd rather hear about a real problem than a polished brief.

— Eduardo

Contact

Send me the messy version.

A half-formed idea, a broken workflow, a weird data problem. That's usually enough to start a useful conversation.

Email Eduardo GitHub