Zingage Engineering

At 3 AM, a scheduled caregiver doesn't show up for her shift. Within minutes, our autonomous agent texts three backup caregivers, leaves voicemails for the client and logs the incident as an open issue. The agent then works the situation. By 7 AM the on-call coordinator picks it up — alongside however many other overnight escalations are waiting — and her job is to figure out, quickly, what the agent did, what worked, and where she needs to step in.

For months, what she opened was closer to a database dump than a timeline. Nine near-identical "Sent EMR chat message" entries, each a paragraph of metadata: timestamp prefix, recipient name buried mid-line, full message body, status code. To find out who the agent had reached, she had to read most of every entry. The data was all there. The interface surfaced almost none of it usefully.

This is the standard failure mode for an interface built as a thin skin over an event stream: faithful to the database, indifferent to the person doing the work. Coordinators don't slow down to read. They pattern-match, triage, and move on. When a UI doesn't match that rhythm, they route around it. Which means they route around us.

The Diagnosis

None of the four issues below are unusual on their own. Together they made the timeline functionally hostile.

1. A log, not a workflow. Every agent action — sending a text, posting a comment, transitioning a status — rendered as a flat system entry of the same shape. There was no surface-level difference between "the agent sent a message" and "the agent escalated this to a human." Both were just sentences.
2. The most important field, buried. When a sent-message event matters, the field you need first is who received it. In the old layout, the recipient name appeared after a timestamp prefix and a type label — eight or nine words into a paragraph. To answer "who did the agent text?" a coordinator had to scan past two pieces of structural metadata before reaching the content she actually needed.
3. No visual hierarchy. Same typography, same indent, same row height for every event. State transitions, sent messages, system notes, and human comments all looked alike. Nothing popped because nothing was allowed to.
4. Doomscrolling on burst actions. Coverage outreach commonly produces a burst — the agent contacts ten or twenty potential backups within a few minutes. In the old design every event got a card-sized vertical slot, so a single burst could fill the viewport and push the structural events below the fold. Coordinators routinely lost the shape of an issue inside its own activity.

How we approached the redesign

A timeline for operators is a specific thing. It is not a feed, not a notification stream, not a log. It is the primary surface through which a human reconstructs a sequence of mixed human and machine decisions under time pressure. Before writing a line of new UI, we named what a great one had to do.

There was no blank-slate moment. The timeline was already in production, used every day. Any redesign had to ship as a drop-in replacement on the existing data model — no schema migration, no historical-data backfill.

Pillar 1: Signal Over Noise

We collapse runs of same-type events from the same actor into a single card. Twelve "Sent EMR chat message" events from the same agent within a short window render as one card — Send EMR chat message (12) — with a compact list of recipients beneath it. Each recipient row leads with a bolded name, followed by a one-line message preview and a status tag.

Per-event timestamps live in a hover tooltip on each recipient row. They aren't removed, just deferred — auditability preserved without paying for it on every glance.

Pillar 2: Context on Demand

Progressive disclosure is unremarkable as a principle. The interesting question is where to put the disclosure boundary.

The new UI expands a sent-message card in place. Click the card and the full thread opens beneath it as a chat-bubble stream — caregiver replies, agent follow-ups, rejections, acceptances — in the visual format people already use for messaging.

A chat bubble carries causality cheaply: who answered whom, in what order, with what tone. The breakthrough wasn't the format itself; it was matching the format to a genre coordinators already know how to read.

Pillar 3: State Visibility

The timeline carries two kinds of information: events and states. The old design treated them identically, which meant the issue's state lived nowhere visually — you reconstructed it by reading.

The new timeline breaks at every state transition with a horizontal rule labeled with the new state and the time of transition. Scrolling an issue, you see the skeleton first: opened at 3:27, escalated at 3:45, transferred at 4:29, resolved at 4:52. The events between the rules are the meat. The rules themselves are the bones. A coordinator orienting to a new issue reads the skeleton in under a second and dives into whichever bone-section is relevant.

The other piece of state is the present tense. When an agent is actively working an issue — calling, posting, waiting on a reply — the issue footer shows a live indicator. This is the question coordinators asked us about most often, in one form or another: is the agent still on this, or has it given up and is this now on me? In the old UI, ambiguity defaulted to "I'd better check," a tax on the coordinator's time on every issue. The indicator answers without being asked.

Pillar 4: Clear Ownership

Every event on the timeline carries an author: name, avatar, timestamp, in that visual priority. The bolded name is the fastest piece of information on the card.

This sounds like cosmetic discipline. It matters most on handoffs. An issue that gets escalated to a human, transferred back to an agent, then closed by the customer touches three actors. The coordinator picking it up needs to know whose context she's inheriting. The rule we hold to is straightforward: no event renders without an explicit author.

Mobile

Enterprise software historically treats mobile as an afterthought, which is strange, because a coordinator on-call is almost never at her desk. The new timeline is the same timeline — same aggregation, same event cards, same expandable conversations — fit to a phone. The old mobile view was effectively unusable for anything but the simplest issue. The new one is the one coordinators actually use.

What this taught me

The coordinators we build for are triaging real situations — a missing clock-in is a missing caregiver is a patient who may or may not have gotten their meds. The design budget should reflect that. A few hundred milliseconds saved on a triage flow, multiplied across a shift, multiplied across every coordinator in every agency we serve, is time that goes back to the people who need it.

And finally — Every choice in this redesign has trade-offs. Aggregation buys scannability at the cost of direct timestamp visibility. We pay it back through tooltips and expansion, but we don't fully neutralize it: a power user who wants to see all twelve timestamps at once has more clicks than before. The right call depends on who the surface is for. Ours is a coordinator under time pressure who needs to triage fast without missing anything. If a similar timeline is being designed for forensic reconstruction — post-incident review, compliance audit — the defaults probably flip: more density, less aggregation, timestamps surfaced rather than deferred.

We're hiring engineers who care about this kind of work. Open roles: jobs.zingage.com.

Home care is breaking. Medicaid waitlists stretch longer every month.

Schedulers burn out faster than 911 dispatchers. Clients lose coverage because one form got filed a day late. And somewhere in the chaos, a caregiver is driving across town to a shift that got canceled two hours ago.

AI can change all of this. The question isn't whether you'll adopt it—everyone will. The question is whether you'll use it to patch the old way of doing things, or to build something fundamentally new.

This is the choice every home care provider now faces. And like a famous scene from a my favorite film, it comes down to two pills.

🔵 Take the blue pill, and AI becomes a better toolbelt for your admin team. Your schedulers still log into the EMR every morning. They still wake up on Saturdays to a flood of texts from caregivers calling out. The work gets a little faster, a little easier—but it's still the same work, done by the same people, hitting the same ceiling.

🟠 Take the orange pill, and AI stops assisting your operations. It starts running them. Calls get answered on the first ring, every time. Compliance doesn't slip through cracks because there are no cracks. Your people stop firefighting and start building—growing census, deepening referral relationships, actually talking to patients.

The blue pill measures quality the old way: a human voice on every call, even if half go to voicemail. Manual processes, because that's how it's always been done. A patchwork of vendors held together with duct tape and good intentions.

The orange pill measures quality differently: total capacity to deliver care. Zero dropped calls. Zero missed authorizations. Zero hours lost to screens when they could be spent with patients.

We're entering an era of accelerated pressure. By 2030, one in five Americans will be 65 or older—and the population of potential caregivers will have grown by just 1%. Meanwhile, Medicaid Fraud Control Units recovered $1.4 billion in 2024 alone, with personal care attendants accounting for 36% of fraud convictions. EVV mandates, billing audits, eligibility reviews—the compliance burden isn't shrinking. It's compounding.

The agencies that survive will be the ones whose operations can scale without adding headcount for every new patient.

The choice is yours. But we know which pill we'd take.

Strolls on the Presidio Promenade or nightclubs in Nolita; we all made the hard choices about where to live and build. The talk of remote work and “moving back home” faded like paper vaccine cards. We found our groove, got hitched, settled into brownstones and high‑rises. And yet a question keeps echoing from the burbs: who’s taking care of grandpa?

That’s the question millions of city‑dwellers will face this decade. And it isn’t as easy as booking a ride home. The harsh truth: no matter how high that TC (total comp) goes, finding the right caregiver for our parents is a problem bigger than money. The home front needs care and it’s time for our best minds to make that happen.

I think about Vinesh, a PhD dropout whose family immigrated when he was three. His father came on a student visa to study engineering in Kentucky. They lived the American dream: from middle class aspiration and entrepreneurship to elite education and a real retirement plan. Vinesh lived up to his parents’ ideals: hard work, dedication, service.

Then, in his thirties with a son of his own, came what no one planned for: a father with cancer, hundreds of miles away. At first, logistics didn’t matter. He flew home, met doctors, sorted insurance. The system, slowly, stubbornly, worked. His dad’s care team got him on the right treatment. Crisis averted.

But Dad wasn’t the same. And Mom had aged a decade in a few years. Vinesh wasn’t ready to give up the life he’d built in the Valley. He needed to be home. But “home” now meant two places now.

So began his journey into home care. First call: Senior Helpers, the long‑respected private provider serving thousands. The first caregiver was new to the agency but handled Dad’s care plan well: groceries, appointments, even learning to play Carrom. Then the call‑outs started. A later visit was fine. Until it wasn’t. A no‑show. Then a different caregiver every week. His calendar filled with blocked time to interview other agencies. He quickly realized: this wasn’t an exception; it was the norm.

Senior living? Mom wouldn’t hear it. Home was non‑negotiable. And so the hard choices stacked up. His dreams in one hand, his family in the other. Onward he went, in pursuit of the perfect caregiver.

This is the hidden truth today and the visible future for many more. We dreamed of big city lives and dread the nightmare of our parents with no one to care for them. At Zingage, we’re a collective of builders who know this struggle intimately. We’re building to solve it. And while we’re making progress, it’s still Day 1.

Thousands of seniors don’t have a son like Vinesh or the resources for top quality care. There is a path forward. It starts by empowering the providers dedicated to caring for our parents and by convincing the best engineers in SF and NYC to aim their talent at the home front. If that’s you, let’s build for dad in Louisville.

One of our core values at Zingage is velocity. Startups are a dogfight and to win you need speed. But you also need direction.

We chose velocity because velocity is a vector. It is not just a measure of speed but also direction. Going fast only matters when you are going the right way. What most people miss is that velocity looks different for different people.

Building high velocity teams means understanding the role everyone plays in the collective velocity of the company. I have always understood this through the lens of rowing and how we built a crew. For those familiar, Crew is the ultra WASP sport of northeast prep schools. It was one of my biggest motivators to attend Exeter. Coming from New York, the closest I had been to a boat was the Staten Island Ferry.

After my first year on the crew team I was invited to the varsity pre-season in March. We broke the ice with our oars in skintight spandex before spending hours on the Charles River. This was where I first saw how coaches selected the composition of boats, known as “crews.” Each crew had eight rowers and one coxswain. The big guys who looked like the Winklevoss twins sat in the middle. The lanky guys who looked like cyclists or cross country runners either sat in the stroke and two seat, setting rhythm for the rest of us, or they served as the bow pair, feeling every wobble of the shell and adjusting before anyone else noticed.

It is not easy to see why small changes in that composition can alter the boat’s velocity. The clearest way you learn this is when random pairs are sent to row two-man sculls. Take two inexperienced rowers from seat three and stroke, and the boat spins in circles. Scale that to eight rowers and even a slight misplacement can ruin your crew’s chances of reaching Henley.

When I think about velocity at Zingage, it’s never about how fast one engineer ships a feature. It’s about how the whole boat moves.

There’s a lot of noise about 996. We only believe in it in two specific moments as a gear, not a lifestyle:

1. The final sprint: the last 300 meters when the call comes and everyone empties the tank.
2. Power sprinters: the engine seats that can throw down big watts on command during the body of the race.

Those two moments only work when each seat knows its job.

Your product and engineering leader is the coxswain. She sets direction. Her voice is the only one everyone hears, and when she calls for “ten hard” or “more from port,” you fucking pull because she’s the only person who can see the line we’re taking and what it will take to win.

Then there’s the stroke, usually the most senior engineer. The stroke sets rhythm and rate so the boat can sustain speed and still have a kick left. When the cox calls, the stroke lifts the cadence cleanly so everyone can follow without blowing up.

Next comes the Engine Room aka the power seats. This is where many new grads and junior devs start. Your job here is torque: clean, heavy pulls in rhythm, plus short, violent bursts when the boat needs it. That’s what I mean by power sprinters. You don’t pace the race. That’s the stroke’s job, but you decide it by delivering coordinated power without throwing the set. Done right, this is 996 in micro: intense, time‑boxed effort that serves the boat, not a performative grind.

Finally, there’s the bow pair, our stabilizers. They’re the technicians who keep the set, feel the crosswind first, and make the subtle corrections that keep the shell running straight. In a startup, these are the quiet pros who keep quality high, spot risk early, smooth releases, and protect customers when things rock.

Velocity is a vector. It belongs to the whole crew. Know your seat, pull in time, and make the boat fly.

“Hello, this is Linda from MediCorp—how may I assist you today?”

While Meta plows billions of dollars into one‑shotting seniors to become fodder for the leviathan, healthcare builders are wading through the ugliest stretch of making care great for everyone. This is the part where frontline founders feel the pain of close‑but‑not‑quite models. From mechanical tone to medical‑code hallucinations, we’re so close and still uncomfortably incomplete—just shy of automation that doesn’t make you wince.

Welcome to healthcare’s uncanny valley. It hurts because we know what great looks like. We know how good it will be when voice AI sounds like the receptionist you’ve spoken with every week for years. We know how deliriously happy it feels when the paperwork isn’t work at all.

I dream of a world where health just happens—where regulations don’t slow my grandmother’s care and the nurse is listening, not note‑taking. A world where care coordination means house visits to patients, not mouse clicks in Epic. Our mission is to make that world real.

Most healthcare AI vendors will tout a perfect product. If this is what “perfect” looks like to them, we’re in trouble. In senior care, we benefit from an older ear that’s happy to hear any voice instead of a dial pad—even if it sounds a little too happy sometimes. Our customers know this is still Day 1, and they’re committed to the journey because any future is better than the present.

At the same time, the bar is higher for healthcare AI builders. We’re not judged like humans doing their best to keep up. We’re measured against do‑no‑harm at a scale that prizes coverage over novelty and stability above all. The companies we’re building now will orchestrate care for billions. Before we get there, we’ll keep doing the hard work in the bowels of infrastructure and prompting—to make it work, and make it human.

At Zingage we're doing this hard to make AI actually work in Home Care. If you're interested in learning how we're tackling this problem with Zingage's data platform, check out our latest piece: How We Built a Data Platform for AI Agents.

When Zingage first launched, our data infrastructure looked like many early-stage systems: cron-driven ETLs, periodic syncs, and a warehouse where truth converged slowly. It worked — until we stopped reporting on care and started orchestrating it. Once we began making calls, scheduling visits, and updating records, the abstraction broke. Our software entered the physical world, and the physical world doesn’t wait for nightly jobs.

We saw the failures immediately: Voice AI calling caregivers about visits that were already closed. Operators overwriting each other’s edits. Automations racing humans across time zones on inconsistent state. None of these were application bugs—they were contradictions born from stale or conflicting data. We had treated consistency as a global property. In practice, it’s actor-specific. We rebuilt our data layer not just to scale operations, but to give AI agents a consistent and reliable view of the world they operate in.

From Batch to Proxy

We realized a shift was needed: stop asking “how fresh is our data?” and start asking “how coherent must it be for this actor, right now?” The answer changes by use case. The Voice interface needs near-instant coherence. The scheduling dashboard needs read-your-own-writes. The payroll export can live with delay.

The only architecture that could express those guarantees cleanly was a proxy layer. Every read and write now flows through Zephyr, our data plane. It doesn’t blindly fetch data—it reasons about which data to serve, how stale it can be, and what level of consistency each actor requires. Each request includes Consumer Directives: latency budgets, staleness tolerance, and consistency guarantees.x

type ConsumerDirectives = {
  maxStalenessMs: number;
  requireReadYourOwnWrites: boolean; // RYOW guarantee
};

When the proxy sees a read, it asks: “Given this actor’s contract, what’s the most coherent view I can safely return?” That framing—no single master, only policy-governed caches behind a proxy—reshaped everything.

Defining Correctness in a World Without a Master

Once we abandoned a central datastore, we faced a deeper question: when there’s no monolithic database, what does correctness even mean? Traditional databases give you consistency for free through ACID transactions. Zephyr doesn’t have that luxury. EMRs, HR systems, and operator dashboards all modify overlapping slices of reality. We had to invent our own invariants—rules that make a decentralized system behave predictably.

The first rule: explicit ownership. Every field in our merged graph is annotated with a single physical writer; everything else is derived. That map underpins merges, conflict detection, and write routing.

const OWNERSHIP: Record<string, "EMR" | "HRIS" | "ZINGAGE"> = {
  "visit.scheduledStart": "EMR",
  "visit.scheduledEnd":   "EMR",
  "visit.timeEntries":    "EMR",
  "practitioner.language":"HRIS",
  "assignment.status":    "ZINGAGE",
};

At read time, Zephyr uses this ownership map to deterministically merge records. When external IDs align, identity is clear. When they don’t, we fall back to a learned policy that defines what counts as “the same visit”—matching patient, caregiver, and service day within an adaptive epsilon (ε). The epsilon adjusts per integration, based on observed rounding and clock-in drift.

/* Fallback identity predicate for read-time reconciliation.
   ε (epsilon) is per-integration tolerance to account for drift. */
SELECT
  external_id_a IS NULL AND external_id_b IS NULL
  AND caregiver_a = caregiver_b
  AND patient_a = patient_b
  AND date_trunc('day', start_a AT TIME ZONE biz_tz)
      = date_trunc('day', start_b AT TIME ZONE biz_tz)
  AND tstzrange(start_a, end_a)
      && (tstzrange(start_b, end_b) + make_interval(mins => :epsilon_minutes))
AS is_same_visit;

Writes enforce the same invariants in reverse. Every update carries an ETag (Entity Tag) so the proxy can detect concurrent edits and preserve read-your-own-writes. If two writers race, we return a deterministic 409 Conflict with a structured diff—never a silent overwrite.

async function updateVisit(id: VisitId, patch: Partial<Visit>, ifMatch: string) {
  const current = await loadNormalized(id);
  if (current.etag !== ifMatch) {
    return {
      status: 409,
      body: {
        code: "ETAG_MISMATCH",
        current,
        diff: computeDiff(current, patch),
        hint: "Rebase and retry with new ETag",
      },
    };
  }

  for (const field of Object.keys(patch)) {
    if (OWNERSHIP[`visit.${field}`] !== "ZINGAGE") {
      throw new Error(`Cannot edit non-owned field: ${field}`);
    }
  }

  await sagaWriteToOwners(id, patch);
  const next = await loadNormalized(id);
  return { status: 200, body: next, headers: { ETag: next.etag } };
}

Together, explicit ownership, adaptive identity, and conditional writes form Zephyr’s version of a transaction. And because Zephyr doesn’t maintain a canonical datastore, the system effectively operates as multi-master. AxisCare writes clock-ins, HRIS manages caregiver metadata, Zingage orchestrates assignments. Zephyr reconciles them all at read time. In practice, it behaves like a business-logic CRDT - conflict-free not by algebra, but by policy.

The Zephyr Data Plane

With correctness defined, we built the plane to enforce it in real time. Zephyr has four layers: Source Translators (one per EMR), the Proxy Layer (decision engine), a lightweight FHIR-inspired model (shared vocabulary), and Per-Actor Caches (snapshots governed by freshness policies).

The diagram below shows how Zephyr reads from an EMR, normalizes data into a unified schema, and streams it into the cache and event topics for consumption.

Each request is a policy invocation. Actors—voice, UI, or batch—define how fresh data must be, how much latency they can tolerate, and what consistency semantics they require.

type ConsumerDirectives = {
  maxStalenessMs: number;
  requireReadYourOwnWrites: boolean; // RYOW guarantee
  latencyBudgetMs: number;
};

When a read lands:

async function getVisit(id: VisitId, policy: ConsumerDirectives) {
  const cached = await cache.get(id);
  if (cached && !isStale(cached, policy)) return cached;
  if (cached) revalidateInBackground(id);
  return await fetchFromSource(id);
}

This yields bounded staleness per actor, not a single global metric. Voice AI trades detail for speed. Dashboards require stronger coherence. Batch jobs prioritize throughput. Each interaction is negotiated.

Writes follow the same pattern—conditional, versioned, and deterministic.

When failures happen, we aim for predictable degradation, not brittle coupling. If an EMR is unreachable, the proxy fails fast on those fields but continues serving Zephyr-owned state flagged as “pending-sync.” Schema drift is quarantined, not guessed. We track per-actor coherence: p95 latency, stale ratio, invalidation lag. The key question isn’t “is the system up?” but “is each actor seeing a coherent world within the bounds it was promised?”

What’s Next with AI: Self-Healing Data at the Edges

With Zephyr’s consistency layer in place — ownership, merging, conflict logic — there’s still plenty left to build. But LLMs today has opened a new set of possibilities. We’re beginning to explore how AI might help Zephyr repair itself: flagging drift, suggesting schema patches, or even filling gaps when systems fail. Below are a few directions that feel especially promising.

Schema Drift

EMRs often change schema: drop, rename, or mutate fields. Those changes propagate silently unless caught. We’re building monitors that detect drift in incoming payloads, propose patches (e.g. remapping fields or migration logic), or issue alerts. We're particularly excited about the research in LLM-Powered Proactive Data Systems (Zeighami et al., 2025), which argues systems should be proactive — rewriting user inputs, inputs’ structure, and query logic.

Data Anomaly & Correction

Data is messy. Records get duplicated, conflict, or violate implicit rules. We plan validator models that flag suspect cases and suggest corrections. Examples: negative durations, timestamp mismatches, out-of-range values. We might output something like:

{
  "verdict": "anomaly",
  "field": "visit.duration",
  "reason": "duration = 0; clock-out missing or wrong",
  "suggestedFix": { "duration": "derive from timeEntries" },
  "confidence": 0.87
}

Depending on policy, we may block writes, stage reviews, or auto-correct high-confidence cases.

Web Agents for UI Remediation

Sometimes APIs break, scrapers drift, or data hides behind UIs. In those cases, a headless browser agent controlled by an AI may log into the EMR portal, navigate UI flows, extract or patch data, and feed it through Zephyr’s same invariants. We treat this as fallback repair, not the primary path.

const uiResult = await runAgent(directive);
if (!uiResult.visitTime) {
  // Use LLM to infer missing field from existing context
  const fix = await callLLM({
    prompt: `Given these time entries: ${record.timeEntries}, infer missing visitTime.`,
  });
  uiResult.visitTime = fix.visitTime;
}
// Feed the result back through Zephyr’s merge + ownership logic
normalized.visitTime = uiResult.visitTime;

If any of this sounds interesting? We’re currently hiring for Senior Engineer to join us and lead our Data Platform. Reach out to Daniel at daniel@zingage.com or visit our job board here.

Our Story

Victor and I never set out to build software for other software people. From the beginning, our goal was a generational company in the real economy - systems that move the world outside a browser tab. Victor had just exited Astorian, a marketplace that helped property managers find contractors. I had just watched my family scramble to find caregivers for my grandfather with dementia during COVID. We didn’t know yet that home care would be our industry, but we knew our ambition belonged where failure has consequences.

We reconnected in 2023 at South Park Commons and started exploring. Our first step was Zingage Perform, a layer on top of the EMR (electronic medical record) to automate communication, engagement, and rewards. At the time we assumed two things: full automation wasn’t yet feasible, and most agencies had foundations we could build on.

We were wrong. The work itself sets humans up to fail. Agencies live in a 24/7 cycle - 2 a.m. hospitalizations, daytime call queues, texts and emails piling up - while trying to coordinate care in systems built for records, billing, and compliance, not minute-to-minute staffing. These are good people doing heroic work inside constraints that make reliability overly dependent on brute force.

So, we stopped hedging and built what we always meant to build: Zingage Operator - coordination infrastructure that frees agencies from the back-office grind and makes care delivery dependable at scale. For a few months we even became schedulers ourselves to feel the weight of it and learn fast. That changed how we work. Every line of code now has a patient on the other end. A race condition isn’t an edge case - it’s a missed visit. A clumsy workflow isn’t an inconvenience - it’s a family crisis.

And now the curve has bent. Since launching post-pilot in August, four weeks of selling took us past seven figures in annual contracts, and we expect to 10x by year-end. Agencies aren’t just adopting; they’re telling us it’s changing their days. Laura Curry, who runs a veterans-focused CareBuilders agency in Kentucky, once bought cruise tickets with her husband and never used them - she was on call around the clock. When she saw Operator in action, she told us it was the first time in years she could put her phone down and know that her veterans would still get the care they needed.

That’s why we’re writing this now. We’ve shared these values internally, but with the team growing, the company at an inflection point, and the stakes higher than ever, it felt right to share them publicly too.

The Zingage Way

Right now, at this moment, there's a caregiver call out that will end in a hospitalization or worse. Families are drowning in chaos: spreadsheets, late-night panics, missed visits, caregivers churning at 80% per year. Zingage exists to end this. We're building the infrastructure so healthcare can happen in the home, so our parents can age with dignity, and so their children can live without sacrificing everything.

We are the coordination layer that makes home care automatic. That's the mission behind every line of code, every sprint, and every late night. We know that behind every bug fix is a family counting on us. Behind every feature is someone's parent waiting for care.

We move fast, bend convention, and take risks others won't. Our customers need us to be this way because their livelihoods and lives depend on it. We courageously build what others avoid, commit to deliver excellence, and uphold the integrity of our commitments.

Zingage may not be an easy mission to achieve but it is an easy mission to champion. Ultimately, our values will determine whether we win.

Customers First

We are building so that every provider, caregiver, and family can live the life they always dreamed.

We build for the providers whose dream is to deliver excellent care to thousands of people without having to give up their own lives staring at screens and staying up late.

We ship so that caregivers who show up for their patients never have to do this alone.

We deliver so that the families who need care can trust they will always get care.

Serving our customers is not only a privilege, it is a duty that we pledge ourselves to fully.

When Zingage succeeds it means that a daughter sleeps easy knowing her bed-bound mother hundreds of miles away will get the care she needs.

It means a caregiver is supported when her patient suffers a stroke in the middle of a visit, instead of being so overwhelmed that they quit.

It means a provider can continue serving thousands of patients without unforeseen compliance hits shutting them down.

Tradeoff: we will prioritize customer impact over internal preferences or engineering elegance, even if it means cutting scope, scrapping work, or redoing something we personally liked.

Velocity

We move fast and we ship responsibly because we care. Our customers’ lives will not wait for us to reach perfect certainty nor will they tolerate careless mistakes. At Zingage we create velocity as a marathon of sprints, punctuated by bursts of intensity and recovery.

We focus on the inputs: work long, work hard, or work smart; pick what works for you, but pick something. Velocity isn't negotiable, but how you achieve it is.

We're pirates. We hired an actress off Craigslist to crash our first conference. We snuck into WellSky's event posing as customers. We hand-deliver donuts at 6am. We take the shots others won't because playing by the rules means families suffer.

We're pirates because this industry needs pirates. The treasure we're after isn't gold, it's every family sleeping soundly knowing care is handled. We burn the ships behind us because there's no retreat when lives are on the line.

In the end, all that matters is what we have done for the customers.

Tradeoff: we accept fatigue and messiness in bursts in order to move fast, but we also commit to cleanup cycles so we can keep sprinting again. If you want a steady, predictable pace, this isn’t the place.

Extreme Ownership

We take extreme ownership at Zingage. We don’t make excuses. We don’t blame anyone or anything. We take ownership of the problems and the solutions. We take ownership because it is the bedrock of trust, which is the lifeblood of success.

Ownership shows up when no one is looking. It appears when you choose to sweat the details to fix a bug no one else caught. It’s there when you go out of your way to teach a customer how to use our product. It’s present when you show up in person to listen and to build beside the customer.

Most importantly, extreme ownership is taking care of each other. There is no blame at Zingage and making excuses without providing solutions is intolerable. When something breaks, we don't point fingers, we make solutions. We not only accept but praise support, encouragement, and respect.

Extreme ownership is the manifestation of high agency. If you want to start a podcast then do it; if you want to understand a customer then call them; if you want to build a feature then ship it.

Tradeoff: we stomach the discomfort of eating shit when we make mistakes and we accept everyone's fallibility. Zingage is not a place you can hide nor is it a place to begrudge teammates who try and fail.

Our mission is worth every difficulty. With these values, we won't just succeed, we'll build a world where no call goes unanswered, no family drowns in chaos, and everyone can age with dignity at home.

A friend and I recently debated the meaning of work in the looming shadow of AGI. The premise was simple: if OpenAI - or any organization - achieves superintelligence, what's the point of doing anything at all?

In truth, I've had this conversation repeatedly with founder friends. Each new OpenAI release sparks awe and dread, steadily devouring startups conceived just months ago. The meme of startups reduced to mere ChatGPT wrappers feels painfully real. These discussions typically land us at two bleak conclusions: either join an AI lab to stay relevant or succumb to nihilism, lounging on Universal Basic Income in the supposed “post-scarcity” future. Advocates imagine humans pivoting gracefully toward art or leisure, but that vision feels patronizingly hollow.

Why does this scenario feel inevitable and limiting? Perhaps because we’ve mistakenly assumed that a single, centralized AGI - one supreme intelligence directing human affairs - is the optimal and natural outcome. Yet history challenges this assumption. Attempts at centralized planning, such as Mao’s Great Leap Forward or Lenin’s collectivization, repeatedly failed due to oversimplification of complex human systems. 

James C. Scott vividly illustrates this danger in Seeing Like a State. Colonial powers in Tanzania enforced monoculture farming, planting a single crop uniformly for maximum yield. Their "scientific" method disastrously ignored local wisdom. Indigenous farmers had traditionally practiced polyculture - planting multiple crops together. While seemingly inefficient and messy, polyculture safeguarded soil health, diversified risk, and allowed flexible responses to unpredictable conditions. The colonial approach, though theoretically optimized, proved rigid and catastrophically vulnerable.

The core misconception underlying singular AGI echoes this colonial mindset: the belief that superintelligence can - and inevitably should - become a digital god capable of making all decisions optimally. Yet real-world decision-making rarely offers neat solutions; it more closely resembles the messy moral complexity of the trolley problem. Intelligence alone, no matter how advanced, cannot dictate correct answers to inherently subjective moral dilemmas. Thus, we must clearly separate intelligence - the neutral ability to solve problems - from agency (authority to act) and values (the moral principles guiding actions). 

Intelligence, in its purest form, involves computational power, data processing, and predictive modeling capabilities. It is fundamentally about pattern recognition, scenario forecasting, and logical analysis - essentially neutral skills that can enhance decision-making but do not inherently carry ethical weight or moral guidance. Agency, on the other hand, concerns who or what has the authority and accountability to act upon the outputs of this intelligence. Agency requires legitimacy, trust, and transparency - qualities that purely intelligent systems alone cannot ensure. Values represent the most human dimension of all; they encompass the moral frameworks, cultural contexts, and ethical considerations that ultimately guide decisions.

Today, systems like ChatGPT already display overarching personalities and value frameworks, intentionally designed by organizations like OpenAI. While this approach helps in establishing baseline safety and ethical guardrails, it presents two significant issues. First, these predetermined values might not fully align with the diverse perspectives, cultural contexts, and nuanced ethical landscapes of all users. Second, embedding a singular value system risks oversimplifying complex moral decisions, potentially resulting in outcomes disconnected from local realities or community-specific priorities. Therefore, a more robust approach would empower users and communities to tailor and tune these AI personalities and values to their specific needs and ethical standards, ensuring greater relevance, acceptance, and genuine alignment.

Startups uniquely embody this critical separation of intelligence, agency, and values. They deploy intelligence as technological infrastructure - powerful yet neutral tools capable of addressing specific problems. They restore agency by enabling local communities and users to actively choose, adapt, or reject these tools based on their distinct circumstances. Most crucially, startups allow values to remain community-defined and responsive to context, rather than universally imposed. For example, a rural healthcare clinic might adopt AI specifically tuned for resource-constrained environments, emphasizing preventive care aligned with local priorities. An urban hospital might choose a different AI optimized for managing high patient volumes and specialist coordination. Each community retains genuine agency, reinforcing accountability and achieving true alignment between technological capabilities and diverse human values.

This approach mirrors how governance functions at its best: overarching federal policies exist alongside state laws, city ordinances, trade associations, and grassroots organizations. While centralized institutions like OpenAI attempt broad alignment efforts analogous to federal policy, startups act as local policymakers - crafting tailored, bottom-up solutions that reflect community-specific needs and values.

Such decentralization doesn’t just enable startups to gain initial traction - it positions them for sustained relevance. Startups rapidly build trust through close alignment with local communities, steadily compounding their advantages by integrating powerful open-source models like Llama and DeepSeek with specialized expertise, proprietary data loops, and deep relationships. These assets form an enduring edge, similar to how local clinicians remain indispensable because their practical insights and patient relationships withstand technological disruption.

Ultimately, I’m not advocating for decentralized intelligence and the startups that embody it out of nostalgia or a luddite fear of our soon-to-come AI overlords. Sure, spending retirement as mediocre painters surviving on UBI sounds grimly amusing. But the real danger is more serious: placing all our trust in a single, omnipotent AI planner whose perfectly rational decisions could lead us straight off a cliff. Startups offer something far better - a morally diverse ecosystem of intelligences, built from the ground up by real communities. If history teaches us anything, it’s that pluralism - not centralization - is our strongest safeguard for human liberty. So yes, despite the looming shadow of AGI, it’s (still) time to build.