ESAR

The Constraint Was the Design

Building for constrained environments forces a kind of clarity that abundant resources never do.

The application had to run on a wide range of low-tier devices — older laptops, underpowered desktops — distributed across hospitals in rural LATAM. There was no API documentation and no established contracts with the central system. I was gathering requirements from hospital staff while simultaneously reverse-engineering how the existing APIs behaved.

The decision to build with Electron wasn't glamorous, but it was right. It gave us a cross-platform desktop runtime, access to local SQLite storage, and the ability to build a familiar web-based UI that practitioners could learn quickly.

Local-First, Sync Later

The best offline experience is the one users never have to think about.

The core engineering problem was building a local-first cache that kept patient data available during connectivity gaps, then reliably synced changes back to the central system when a connection was restored.

This is harder than it sounds. When multiple practitioners update the same patient record independently — one with a connection, one without — you need a strategy for resolving those differences. I implemented a diff resolution module that tracked changes at the field level, flagged conflicts for review, and used JSON transformation to translate between the local schema and whatever the central API expected.

Sync Lifecycle

Diff Resolution

function mergePatientRecord(local, remote) {
  const merged = { ...remote };
  const conflicts = [];

  for (const key of Object.keys(local.changes)) {
    const localVal = local.changes[key];
    const remoteVal = remote[key];

    // No remote change — safe to apply local
    if (localVal.updatedAt > remote.updatedAt) {
      merged[key] = localVal.value;
    } else {
      conflicts.push({ field: key, local: localVal.value, remote: remoteVal });
    }
  }

  return { merged, conflicts };
}

No Documentation, No Problem

When there's no map, you become the cartographer.

Working without API documentation meant treating every network response as a source of truth. I logged payloads, traced patterns, and built a transformation layer flexible enough to handle schema inconsistencies between what the central system sent and what our local model expected.

This experience gave me a deep appreciation for contract-first API design — not as a bureaucratic formality, but as an act of kindness to every developer who comes after you.

Shipped to 10+ Hospitals

The best feedback loop for software is real people using it in conditions you didn't anticipate.

The application was deployed across 10+ hospitals in Latin America. Watching a system you built go live in a rural clinic — used by practitioners who are focused entirely on their patients, not on the software — is a different kind of satisfaction than shipping a web app.

The humanitarian dimension of this project shaped how I think about what software is for. Not every problem is interesting because of its technical complexity. Some problems are interesting because solving them actually matters.

What I Carried Forward

ESAR taught me to design for the edge case first. When connectivity, device performance, and data consistency are all constraints from day one, you build differently. You think harder about what "correct" means when the network is lying to you, and you learn to treat local state with the same seriousness as remote state.

• Electron
• JavaScript
• SQLite
• TailwindCSS
• HTML5