Building an Engineering Organization from Scratch

The Problem

SteadyMD was a digital health platform connecting patients with licensed clinicians through telehealth visits, chronic care management, and EHR integrations. The platform was growing fast and the product ambitions were real, but there was no engineering organization to speak of. No team, no processes, no architecture strategy. Just a product that needed to exist and a company that needed someone to build the machine that would build it.

The technical demands were significant on their own. HIPAA compliance meant every architectural decision carried regulatory weight. Patient data had to be encrypted at rest and in transit, access controls had to be auditable, and the systems handling real-time scheduling and clinical workflows had to be reliable in the way that health tech demands — not “five nines as a marketing claim” reliable, but “a clinician is waiting for this patient record right now” reliable.

Beyond the infrastructure, there was a hiring problem. The company needed engineers who could work in a regulated environment, move quickly without cutting corners on compliance, and operate with the autonomy that a small team requires. Finding those people, convincing them to join, and giving them the context to be effective — that was the actual job.

The Approach

I joined as the senior engineering leader and started from first principles. The first priority was understanding the product roadmap deeply enough to make architecture decisions that wouldn’t need to be reversed in six months. That meant spending time with the clinical operations team, the product team, and the business side to understand not just what we were building but what we’d need to build next.

Hiring came next. I built the recruiting pipeline from scratch — writing role definitions, sourcing candidates, running technical interviews, and making the case for why SteadyMD was worth joining at that stage. I was looking for a specific profile: engineers who were comfortable with ambiguity, who understood that working in health tech means you don’t get to skip the security review, and who could own entire systems rather than just tickets. We built the team deliberately, one strong hire at a time.

On the technical side, I established the architecture patterns for the platform’s core systems. Real-time scheduling between patients and clinicians had to account for provider availability, licensing across state lines, and appointment types with different clinical requirements. The EHR integration layer needed to be resilient to third-party API failures without dropping data. Every system had to be built with HIPAA-compliant logging and access controls from day one — not retrofitted later.

I also stood up the development processes that let a small team operate at high velocity without accumulating the kind of technical debt that kills health tech startups. Code review standards, deployment pipelines with proper staging environments, incident response procedures, and on-call rotations that were sustainable for a team our size.

The Outcome

The engineering organization I built supported SteadyMD through its period of fastest growth and ultimately through the acquisition by DocGo. By the time of the acquisition, the team had a clear technical roadmap, well-documented systems, and the kind of operational maturity that holds up under due diligence scrutiny.

The platform handled real-time clinical scheduling at scale, maintained HIPAA compliance across every layer of the stack, and integrated with multiple EHR systems without the fragility that typically comes with third-party healthcare integrations. The systems I architected continued to serve as the foundation of the product well after the acquisition.

More importantly, the team itself was the deliverable. The engineers I hired and the culture I built — ownership over process, directness over politics, quality as a default rather than an afterthought — survived the transition intact. That’s the part of building an engineering organization that matters most: whether it keeps working when you’re no longer in the room.