A decades-long paperwork burden became a company idea
After two decades in hospital medicine and emergency care, Adam Z. Kawalek, MD, recognized something many physicians experience but rarely name: the most persistent frustration in practice can be a market opportunity. Across academic medical centers and critical access hospitals in Alaska, California, Hawaii, and beyond, one task kept returning every shift, in every setting, with the same clinical monotony. It required physician attention, absorbed time, and produced little direct patient care value.
The burden was administrative, but its effects were operational. A recurring paperwork task followed him from tertiary hospitals to remote sites, which made it visible in a way that isolated complaints never could. For years, it blended into the background of workflow, passed over because medicine normalizes friction when it becomes routine. The moment of recognition came only after a forced pause in clinical work, when a staffing company bankruptcy left him with unexpected time to think and a reason to measure the problem instead of just tolerating it.
He approached the issue the way clinicians are trained to approach repeated symptoms: quantify the pattern, test the assumption, and look for the underlying cause. By estimating the share of emergency physician hours spent on encounters that existed only to generate a signature, he arrived at a number large enough to change his thinking. The paperwork itself became the product. The idea had been sitting in plain sight for 20 years, embedded in the daily rhythm of care, waiting for someone who understood both the workflow and the cost.
Medicine often teaches physicians to accept inefficiency as a fixed feature of the job. In this case, the inefficiency was the business case.
Why the first build failed and the second one moved faster
Kawalek started the company without a business degree, without coding experience, and while still practicing. He began the way many physicians do when they step outside their own lane: by seeking experts. A 10-week online business course provided vocabulary, but not traction. Conversations with people in private equity and corporate life reinforced a common startup mantra, yet the practical challenge remained unsolved: how do you build quickly when a product needs daily iteration and the traditional software process moves in larger, slower increments?
The first approach relied on a conventional team structure with written requirements and tickets for each change. In medicine, rapid feedback is normal; in software development, especially early in a build, that structure can become a drag. A fix that should have taken an afternoon instead became a queued request for the following week. The product needed constant adjustment, but the process assumed stability that did not exist.
He also discovered that accountability does not translate automatically from the hospital to the startup world. In the emergency department, a promise made in a room tends to be followed by visible consequences if it is not fulfilled. Outside medicine, the same urgency was absent. Delays accumulated, emails replaced action, and momentum drained away. The mismatch between clinical culture and business culture was not subtle. It was operational.
Then came the pivot. Days before making another decision, he tested an AI coding assistant by asking whether a physician with no coding background could build the product by describing it in plain language. The answer was yes, and he let the entire team go except for one younger collaborator who shared the mission. The shift was not a celebration of automation for its own sake. It was a recognition that product knowledge, when deep enough, can outrun formal technical dependency.
The physician who understands the workflow often knows more about the needed software than the people hired to build it.
Building with an AI assistant while still practicing medicine
What followed was less glamorous than many startup narratives suggest. On day three, the assistant forgot what had already been built because the system had not been documented in a way the model could reliably use. Kawalek adapted by treating the AI like a new resident and creating two core documents: a rulebook and a running progress log. Those files were reviewed at the start of every session and updated at the end. In effect, he created a memory scaffold for the machine and a process discipline for himself.
That structure became central to the company’s operation. Over the next 180 days, he shipped more than 3,300 changes without an engineering team while continuing full-time work in virtual urgent care. Most back-end changes passed automated testing before going live. The pace was possible because the physician-founder stayed close to the product and treated the build the way clinicians treat a difficult diagnostic process: check, re-check, document, and avoid over-trusting a single confident answer.
The learning curve was steep, and the tools failed often. For a physician, that can be unnerving. Clinical training rewards systems that are reliable and repeatable; startup work forces the opposite lesson, at least early on. He had to learn to verify output, ask the same question twice, and regard a polished answer from AI the way an attending might regard an intern’s first pass at a complex history. Confidence alone was not enough. Verification remained essential.
Colleagues also questioned whether he was still a real doctor. The answer was unchanged. He never left medicine; he simply built a product around a problem medicine had trained him to ignore.
Six lessons for physicians who want to build without leaving practice
Kawalek’s advice to other physicians begins with a simple premise: do not outsource the first proof of concept before you know what the product actually is. Build the worst version that works. Test it on strangers, not friends, because supportive people are not market validation. He argues that physicians should determine what can be done personally before hiring for functions that may not yet be necessary.
His second lesson is financial discipline. Before hiring, ask what the role truly yields, what it costs, and what happens if the position does not exist. He has repeatedly considered hiring a chief technology officer and has not done so, not because technical leadership is unimportant, but because early-stage spending can become a form of comfort rather than necessity.
He also emphasizes how physicians should evaluate people. Judgment and steadiness matter more than technical bravado, and references should be checked with the same care used in chart review. Money cannot compensate for poor ownership, and enthusiasm does not replace reliability. In this setting, the right hire behaves less like a vendor and more like a clinician who understands consequences.
Writing everything down matters too. In medicine, documentation is a memory system, a legal record, and a communication tool. In startup work, it serves the same purpose and one more: it allows a human and an AI tool to operate with continuity. Without written structure, the machine forgets and the founder spends time reconstructing what already happened.
The final lesson is the most recognizably medical. Close what is not working. Physicians are trained to abandon ineffective treatments when the data justify it, without clinging to ego or sunk cost. He applies the same standard to business ideas and advises other physician-founders to do the same, even when a concept has already absorbed time and money. He also insists that the physician should overrule the businessman when patient-facing decisions are involved, especially around data disclosure and access to help before payment.
The practical consequence is straightforward: physicians who understand clinical workflow are often better positioned than outsiders to solve the software problems embedded in care delivery. The challenge is not whether they can identify the burden. It is whether they are willing to measure it, keep practicing, and build something around it without mistaking familiarity for inevitability.