Why we built it ourselves: Anthony Comito on the making of Koda Compass

CTO Anthony Comito on the moment it became clear health systems didn’t need another ACP tool, why the calculus on building versus buying flipped this year, and what it took to go from a napkin decision to production in ninety business days.

The problem that led to Compass

The gap was never a missing tool. It was the labor and coordination underneath one. Advance care planning is one of the hardest workflows in healthcare to operationalize: fifty states’ worth of different forms and legal requirements, a patient who fills out half a form and doesn’t come back for three months, a medical decision-maker who isn’t reachable for three weeks. Real alignment takes multiple conversations, not one, and knowing when a patient’s clinical status has declined enough to warrant revisiting the conversation is its own challenge.

Every one of those touchpoints was happening in a different place, so piecing them back into a single, coherent picture of where a patient stood kept getting harder as we scaled. The problem was never the tool. It was everything underneath it.

Why build instead of buy, and why now

We weren’t short on tools. We had an email platform, an enterprise CRM, a marketing-journeys tool, an outside phone system, a scheduler, each one fine on its own. What we didn’t have was any of them talking to each other. An advocate prepping for one call was jumping across four screens just to piece together where a single patient stood. The signal that would have told us the right moment to reach someone, an email opened, a call from yesterday, a guide abandoned mid-question, sat locked inside whichever tool captured it and never reached the tool that needed it.

For years, the industry consensus was simple: you don’t build a CRM from scratch, you buy one. A new feature meant two options, build it ourselves in two months or configure it in Salesforce in two weeks. Framed that way, building on top of Salesforce always won.

Then AI changed the math. As models got good enough this year, a two-month build became closer to a two-day build. The configuration work inside an off-the-shelf platform started taking longer than building the real thing with a coding agent. That’s the moment the calculus flipped: we could iterate faster building our own than buying and bending a general-purpose tool would ever let us. Salesforce is a sales tool. We were forcing it into being a patient engagement and management platform, a related job but not the same one.

There wasn’t a moment we almost bought a sixth tool instead of building. It was more that the evidence kept piling up, once we saw how fast coding agents let us move, that owning this layer ourselves was simply the better option.

What building it actually looked like

Nine people, nine months to production, though the timeline wasn’t linear. There was a long stretch of tinkering, prototyping, and debating whether to do this at all. It’s a big decision. The first code was written in October, and we weren’t fully committed as an organization until January. Once we committed, we built it in about ninety business days.

The surprise wasn’t how much coding agents let us get done. It was that getting the details right was still just as hard as it was before AI. The agents removed a lot of the slow part of the work, not the hard part. We weren’t alone in this either; other startups were moving off Salesforce for the same reasons around the same time.

Migrating data out of a legacy system is never easy, and this was no exception. But the bigger shift wasn’t a technical problem, it was rethinking how the team worked. We used to run two-week sprints: an idea would come up, and five or six people would sit in a room estimating how long it would take to build. That stops making sense the moment something only takes an hour to build.

The bottleneck isn’t the code anymore, so the real question becomes what a software factory looks like when writing code isn’t the constraint, delivering continuously instead of batching everything into a sprint cadence. That’s a question the whole industry is wrestling with right now.

I went from shipping a handful of pull requests last October to shipping around 500 by this July, from a fairly traditional CTO role to someone writing code full-time. I addressed the early skepticism on the team not by arguing the case but by doing the work alongside them and setting the model myself. That shift mattered as much as any single technical decision we made.

Why “always watching” is the point

A static workflow can’t keep up with a patient whose condition is changing in real time. For engineering, that came down to one concrete problem: who do we reach out to next? We were wrestling with Salesforce trying to figure out which patient was most receptive and most in need at that exact moment, which is where the name Compass comes from. It’s meant to point us toward the right next patient, not hand us a static list, so patients get attention when they need it, whether that’s across a statewide network, a national partner, or a single hospital relationship.

Picture a snowbird patient, home up north most of the year, in Florida for the winter, who has a medical event or decline while away from their primary care provider. Koda should already know it might be time to check in on their advance directive, without anyone submitting a referral first. On the provider’s side, they log in and the patient’s plan is already updated, with no extra work on their part.

We want it to feel like magic. The magic is really just the queue and the algorithm underneath it, pulling every relevant data source together so outreach happens at the right moment instead of on a fixed schedule.

Where Compass goes from here

In two years, I want Compass to be more connected, above everything else. We’re collecting genuinely valuable data now, decision-maker contact information, plan alignment, frailty decline, and I want that feeding directly into a provider’s view and into the EHR itself, not sitting in a system next to it. I want Compass to be a real repository for a patient’s care preferences that takes input from a KodaCares Advocate conversation, our voice AI, or a provider entering something directly, all feeding back into the same record across every practice a patient touches, not just the one that started the conversation.

The part of this architecture that generalizes beyond ACP is exactly why I don’t think of Compass as an ACP tool with a name. It isn’t the ACP-specific logic. It’s the underlying pattern: watch continuously instead of on a schedule, know enough about a person to tell when something’s changed, and route to the right attention, digital or human, the moment that happens rather than at the next scheduled touchpoint.

None of that is specific to advance directives. Swap out what you’re watching for and what “the right conversation” means, and the same architecture applies to chronic disease management, care transitions, and any value-based care problem where an organization is accountable for an outcome that plays out over months, across multiple people. Advance care planning is one of the hardest versions of that problem, which is part of why we built it first.

Reach the right patient at the right moment.

See how Compass coordinates advance care planning outreach across your organization and writes results back to your EHR.