From patient care to browser extensions
Jack Lipchik's path to software engineering did not run through a computer science program. It ran through occupational therapy — a discipline focused on helping people regain functional independence after injury, illness, or disability. The skills are not as different as they sound. OT is fundamentally about understanding a system, identifying where it breaks down, and designing interventions that let the system function the way it's supposed to. Software engineering, at its best, is the same thing.
The transition happened through curiosity rather than planning. Jack started learning to code the way most self-taught engineers do — small projects, growing ambition, the gradual realization that he could build things that actually worked. The difference between dabbling and committing was the moment he understood that software was not a separate discipline from the human-centered thinking he'd developed in OT. It was just another way to express it.
"In OT you're always asking: what is this person actually trying to do, and what's getting in the way? In engineering, the question is identical. The medium is just different."
Building CoApp's extension layer
CoApp's core product is a browser extension — a piece of software that lives inside the browser, reads the DOM of whatever web application the user is working in, evaluates field values against configured rules, and surfaces alerts when something looks wrong. Building that reliably across multiple browsers, multiple practice management systems, and enterprise deployment environments is a non-trivial engineering problem.
Jack owns that problem. The extension codebase has to handle the differences between Chromium and Gecko manifest formats, work around the constraints of Manifest V3 service workers, inject content scripts into pages that weren't designed to be extended, and maintain stable selectors across software updates that nobody at CoApp controls. It also has to do all of this without slowing down the workflows it's meant to improve.
The appeal of this kind of work — fragmented APIs, undocumented platform behavior, real constraints with real consequences — is exactly what Jack gravitates toward. He's described the extension as a puzzle that never quite resolves, because the platforms keep changing and the use cases keep expanding. For someone who came to engineering out of curiosity rather than credential-seeking, that's not a complaint. It's the draw.
Curiosity as a professional strategy
Jack's background gives him a particular relationship with unfamiliar technical problems. Where some engineers get anxious when a technology is outside their expertise, Jack treats it as a signal that something interesting is about to happen. The pattern from occupational therapy — observe the system, form a hypothesis, test the intervention, iterate — turns out to be a reasonably good framework for debugging a browser extension that behaves differently on one specific version of one specific enterprise PMS than it does anywhere else.
This attitude has shaped CoApp's engineering culture in a small but meaningful way. The product requires working with systems that CoApp didn't build and can't control. Practice management software is often old, inconsistently structured, and not designed with extensibility in mind. Getting CoApp to work reliably in that environment requires patience, methodical debugging, and a genuine interest in how unfamiliar systems work. Jack models all of those things.
He's also written about the engineering decisions that go into CoApp's extension in more depth on this blog — the Chrome and Firefox extension architecture post and the self-hosted update pipeline post both came directly from the problems he's solved building and deploying the product.
What's next
As CoApp's customer base grows, the engineering surface area grows with it. More practice management systems, more browser configurations, more rule types, more edge cases. Jack is building the foundation that makes that expansion possible — a rule engine that's flexible enough to handle new categories of checks without requiring code changes, a content script architecture that's stable enough to survive upstream software updates, and a delivery pipeline that gets new versions to enterprise workstations reliably and without manual intervention.
The self-taught engineer who started with curiosity and small projects is now the person responsible for the technical infrastructure that CoApp's customers depend on every day. The path was unconventional. The work is real.