Walk into any clinic today and ask a physician how they feel about their EHR. Odds are, you’ll hear about inefficiency, clunky interfaces, and how much time it takes away from patient care. That’s because most EHRs weren’t designed by people who actually practice medicine.

At Counsel, we’re both.

We’re physicians and engineers rethinking the foundation of clinical care. Our mission is to multiply the world’s clinical capacity, and to do that, we’re building an asynchronous-first care model from the ground up. Deciding whether to build or buy a homegrown EHR wasn’t an easy decision. We had many late night discussions and constantly went back and forth, but ultimately realized that our vision wouldn’t be possible with legacy EHRs that are built for a visit-based, reimbursement world. We needed infrastructure purpose-built for how we deliver care, not the other way around.

So, we built our own EHR.

Why Our Model Doesn’t Fit Traditional Systems

Counsel offers unlimited, on-demand access to licensed physicians via messaging. That means no appointments, phone trees, or waiting rooms. Patients message us directly through our app and hear back from physicians within minutes. This model is optimized for accessibility and continuity, with physicians providing ongoing support and advice through a friendly, easy-to-use chat interface.

Unlike traditional in-person care or telehealth appointments, Counsel is creating a new care model that’s designed for responsiveness, personalization, and longitudinal support.

When we started evaluating EHRs, we found most to not only be visit-centric, but also built around scheduling, billing codes, and in-person clinic workflows, which limits their utility to supercharge our care model. While newer ‘headless’ EHRs (i.e. Medplum) provide UI flexibility, most don’t meet the requirements for enabling the speed and flexibility required to iterate and build a best-in-class asynchronous care experience.

Why We Needed to Own the Full Stack

To build the kind of care experience we envisioned, we needed full control over the underlying infrastructure. Owning the full stack allowed us to:

• Own the request cycle end to end: By implementing the frontend UI and backend ourselves, we have full agency on how to architect our application. This includes configuring how to load components, what data to cache on the client vs server, etc.

• Define our own data schema: We built a schema tailored to our unique workflows, tying directly into our app’s core logic, including authentication, routing, and patient context.

• Integrate AI across the product experience: Our stack allows us to embed AI at every layer, from context-aware summarization to LLM-powered note generation. We control which models we use and how they’re deployed, giving us freedom to experiment and iterate.

• Avoid prescriptive vendor limitations: Controlling both frontend and backend lets us rapidly experiment with new clinical workflows, rather than being limited by an EHR vendor’s APIs or rigid setup.

The Result: Speed, Flexibility, and Personalization

This ownership has allowed us to move quickly and build with precision. Many of our most-used features were developed directly from physician feedback, sometimes in less than 24 hours. Highlights include:

• Queue-based triage: Physicians work through structured message queues, not arbitrary inboxes

• Smart routing: Messages go to the right physician, even across shifts, user profiles and time zones

• Scheduled messages: Physicians can queue messages to send later, enabling proactive follow-up

• Contextual UI: Our EHR surfaces details about patients’ payer or employer context to tailor care and documentation

• Outbounds: Physicians can proactively send outbound messages to patients to stay in touch about their health in a personalized manner over a patient’s preferred medium (sms or push).

• Physician co-pilot tools: LLM-powered features like conversation summarization, note drafting, and context recall reduce cognitive burden

By building for our exact needs, we’ve created an EHR that not only powers our current care model, but also adapts with us as we scale and evolve.

Why Now Is the Right Time to Build

Just a few years ago, building an EHR meant starting from scratch. Today, a growing ecosystem of modular, API-driven tools has made it possible to build what we need. We’re not reinventing the wheel, but assembling best-in-class building blocks that let us focus on our differentiators: experience, care quality, and the physician-patient relationship.

None of this is easy. Building an EHR requires significant investment. Collecting and structuring data across multiple systems to make it actionable is complex and ongoing. Each third-party integration also brings trade-offs and operational complexity. However, we’re confident the investment is worth it. Over time, our system will develop a working memory of patient-physician conversations with minimal documentation burden.

That’s not just better infrastructure. That’s better access to the highest quality healthcare.

For us, building an EHR wasn’t just a tech decision. It was a clinical one, as well.