I was the Founder and CEO of Cydoc, a health AI startup, for seven years (April 2018 to August 2025). We achieved what many consider to be validation milestones: paying customers, patents, and demonstrated clinical impact. This article exists because I learned, painfully and expensively, that deploying health AI is only 20% of the challenge. The other 80%, including seamless workflow integration, sales infrastructure, and sustainable business models, is where most health AI companies fail, including mine.

My experience as a founder was an intense crash-course in health AI implementation. After reading this article, I hope you can leverage the lessons I learned to guide your own health AI venture to success.

What we achieved

Cydoc reached several validation milestones that represent significant accomplishments:

  • We built a sophisticated HIPAA-compliant health AI platform for web, Android, and iOS, with innovative AI technology and an intuitive user interface.
  • We deployed health AI technology in multiple practices across multiple specialties.
  • We demonstrated clinical value and measurable time savings. In a research study with 18 medical students, we showed that our AI system saved 11 minutes per visit. More importantly, real customers reported similar time savings of 10 minutes per visit, compounding into multiple hours of time saved every day.
  • We acquired four paying customers. We reached four-figure recurring revenue and five-figure custom development revenue.
  • We were awarded two U.S. patents, validating our technical innovation. We were also awarded a competitive NC IDEA grant.

I won’t bore you with more successes. I know why you’re really here…for the gory dissection of Cydoc’s failures. I’ll tell the story of years 1 to 5, analyze the early mistakes, then continue with the story of years 5 to 7 and analyze the later mistakes. I’ll conclude the chapter with inversions of the mistakes to understand keys to startup success.

The Cydoc story: years 1 to 5

I began working on Cydoc in 2018, four years into my MD/PhD training. By that point I had experienced the interface failings of electronic health records (EHRs) during clinical rotations, and I had experienced the data failings of EHRs through months of cleaning chaotic data as the first step of my PhD research. Obviously, the EHR was broken and somebody had to fix it. I decided that somebody would be me.

I founded Cydoc with the audacious mission to create the first AI-native EHR. The Cydoc EHR would feature an intuitive user interface, AI-ready database, and a built-in AI development and deployment platform that would result in better patient outcomes, saved time for clinicians, and more efficient and affordable healthcare for all.

Building an AI-native EHR like the one I imagined would take millions in funding, but I only had my $35,000 annual MD/PhD stipend. So, Cydoc began with one tiny piece of the vision I was sure doctors would line the streets to buy: automated history taking. We could use the profits from this initial product to add more features until we were a full-blown, bootstrapped EHR.

History taking is the strategic questioning process a doctor uses to elicit key information from a patient. Why automate this? To me, it was obvious: day in and day out, doctors ask patients the same questions over and over. To any patient with a new symptom: “What makes it better or worse?” To patients with pain: “How would you rate your pain on a scale of 1 to 10?” To patients with diabetes: “Do you monitor your blood glucose at home?” This repetitive, rule-based process begged to be automated.

To support a workflow where our software interviewed patients directly, we would need a HIPAA-compliant backend. I would not have time to teach myself backend engineering while focused on learning AI in grad school, and I couldn’t afford to pay professional backend developers off my stipend. I wracked my brains to think of a history-taking-related product that we could build without a backend, and settled on an educational tool for medical students. The medical students could use the tool on their phones. It would tell them what questions to ask patients, they’d key in the answers, and it would generate a note. Why would medical students want this? Because it would make them look smarter, help them get better grades, and save them time on note writing. By the time they became attendings, they would love Cydoc so much they’d buy it for their hospital systems.

I formed Cydoc, LLC, in April 2019, and hired a few undergraduate students as frontend interns. After three years of software development, I discovered a big snafu in our plan: medical students would not be allowed to use our product. During my PhD, I had experienced health system bureaucracy via a complicated process to publicly release an anonymized dataset of CT scans, and from this I realized it would be impossible to get any health system to approve an unknown startup’s software application.

I decided private practices would be more feasible customers, and that our application should take a history from patients directly, which meant we needed a backend after all. To convince private practice doctors that our product was amazing, we did a research study with 18 medical students, which showed that our intake form saved 11 minutes per visit.

After much deliberation about whether to do residency, I decided to focus on Cydoc instead. I started working with professional software engineers instead of interns. By winter 2022, a few months after my MD/PhD graduation, Cydoc’s automated history taking product was nearing “completion” and I realized that I was going to have to do some work to find customers. None had magically materialized as a result of posting the arXiv preprint of our research study.

Thus, I came to my first conversation with a real potential customer in January 2023: Dr. Marum of Southwest Durham Family Medicine. Here is an actual quote from the notes I took during our call:

She wants the patient to complete the form on their device

To identify them she would need their name and birthday

So we’d probably have to get their name, birthday, and email

Then she wants to be able to log in herself and see the patient’s HPI/note already written

[…]

It sounds like she isn’t that interested in the patient history section

Mostly the HPI section

The “patient history section” that Dr. Marum wasn’t interested in refers to separate EHR user interfaces we’d implemented for past medical history, surgical history, medications, allergies, physical exam, and assessment and plan. She was mostly interested in the history of present illness, which leveraged our core automated history-taking innovation. We hadn’t properly thought through the clinical workflow, because we didn’t even have a place for the patient to put their name.

I had drained my savings, but we still needed to do more work on the product. I thus converted Cydoc to a Delaware corporation and between 2023 and early 2024 raised $265,000 from family, friends, and physicians. These generous investments enabled completion of the initial Cydoc product. I also pitched to institutional investors including over 35 different VC firms, but they were not interested in funding a solo founder without any revenue.

Over 2023, we worked closely with Dr. Marum to refine our product until we created the Smart Patient Intake Form. Here’s how it worked: the patient scanned a practice-specific Cydoc QR code with her smartphone. The Cydoc system asked the patient to select “the most important conditions or symptoms you would like to discuss today, up to a maximum of 3.” On the basis of the patient’s chief complaints, our AI system automatically took a history, displaying an individualized set of questions for each patient. For ease of use, most questions were answerable through clicking instead of typing. Our system then transformed the Q&A data into a note, which the doctor could copy-paste into the EHR before the visit.

We added payment processing, achieved HIPAA compliance, and on December 22, 2023 we had our first revenue: $190.36 (after Stripe fees) from Dr. Marum subscribing to our product. She reported time savings of 10 minutes per visit. I thought we were “done.” Now that we had one paying customer, everything else would be easy.

I’ll pause here to analyze multiple mistakes made so far.

Mistake #1: Delayed and minimal customer discovery

The mistake: When I thought our product was for medical students, I talked to my medical student friends and they all said it sounded nice—but I didn’t talk to any medical students from other institutions who could’ve given me impartial feedback, nor did I try to get any students to pre-pay for the product as a sign of true interest. In early 2022 when I decided our product was actually for private practice doctors, I should have immediately attempted to contact private practice doctors, but I didn’t. An entire additional year elapsed before I talked to my first real potential customers. Once I found a doctor willing to work with me—Dr. Marum—I basically stopped talking to other potential customers until we had Dr. Marum using our product. Only later did I discover that Dr. Marum is not a “typical” doctor. She is much more entrepreneurial and tech-forward than the majority of doctors we subsequently interacted with. She is an “early adopter” of new technology.

The consequences: We wasted years, tens of thousands of dollars, and many person-months of labor building features that customers didn’t want, and leaving out features they desperately needed.

Why I made this mistake: One root cause of this mistake is that I simply had no idea what I was doing, since I was learning about entrepreneurship on the fly. But since that’s a root cause of all the startup mistakes I’ll describe in this chapter, I’m not going to dwell any more on it.

There are two other core reasons I didn’t do enough customer discovery specifically:

  • I assumed I was my own target customer.
  • I was afraid of people stealing my idea.

Regarding (1), I thought that because I was a medical student and then subsequently an MD, I was representative of my target customer. I thought that as a doctor—even a non-practicing one focused on health tech—I knew what other doctors wanted. I did not consciously form this thought in words. It was more of an underlying feeling guiding my decision, and only in hindsight did I realize that I had avoided spending time talking to other doctors about what they wanted early on because I thought I already knew.

Regarding (2), as a first-time startup founder, I was afraid that if I talked to too many people about what I was doing, they would immediately see how amazing my idea was, and go out there and build it better. They’d get all the customers, and I’d be put out of business before I even started.

What to do instead: Extensive customer discovery. Customer discovery is the process of interviewing many target customers to understand their pain before you build anything. You should talk to a minimum of twenty target customers, ideally more, and not from the standpoint of trying to sell them your idea, but from the standpoint of understanding what problems they desperately need solved. You can and should get feedback on your idea as part of this process, but the main goal is to understand your customer. If you can talk to a hundred potential customers, even better. Customer discovery doesn’t stop once you have a prototype. It continues for as long as you are searching for product-market fit.

You must accept that you are not your own target customer. Even if you’re a doctor building a tool for doctors, or you’re an engineer building a tool for engineers, you need to do customer discovery.

Ideas are worthless, execution is all that matters, and nobody is going to steal your idea. If you are a first-time founder, you likely don’t believe this at all, because your idea is Different and Irresistibly Stealable. I can think of only two antidotes to idea-theft fear. One option is build your company, fear and all, and experience firsthand how difficult it is to get a functional product in the hands of customers. Then it becomes easier to accept that even if some random person were to “steal your idea,” they aren’t going to execute on it as quickly as you think, and they certainly aren’t going to end up doing it exactly the same way you will. Another option is to find a cofounder with previous startup founder experience, so that he or she can assuage your fears.

Additional notes:

On competition: Competition is good. You are going to have competition regardless of whether you talk about your idea or not. If you don’t have competition, that is a red flag, because it means you aren’t solving a real problem, there’s a massive barrier you’re unaware of, or you’re doing your competitive analysis incorrectly. If you refuse to do customer discovery, you should assume your competition is doing customer discovery and that will give them a big advantage.

On idea-stealing and big companies: The one exception to “nobody will steal your idea” is if you talk to massive technology companies that are extremely mission-aligned with your idea. In that case, you should only share your idea with them if you are confident that you and your team are so ideally positioned to execute on the idea that the big company would rather fund you than build it themselves, and/or that you can still compete with the big company even if they “steal your idea.”

On idea-stealing and NDAs: Do not use non-disclosure agreements (NDAs) during customer discovery. Asking your potential customers to sign NDAs makes you seem paranoid, and gives your potential customers the sense that you don’t trust them, which makes them less likely to be honest with you. If you absolutely must have an NDA, use a boilerplate standard mutual NDA no longer than one page. Never send NDAs to investors.

On knowing the difference between fake interest and real interest: After doing some customer discovery, you may say, “The potential customers seem really interested in my solution. But how can I know for sure that they’ll buy my solution after I build it?” Simple: ask them to buy it before you build it. Once I leaned in to the customer discovery process later on, I realized something interesting: doctors would often say that they liked our product, but if I asked them to invest or subscribe, most made excuses. This is a red flag. If somebody is truly excited about your idea, they should be willing to give you money to support its development. You can ask for preorders, six months of the subscription cost up front, or an investment. If you hate asking for money—which is the case for me—swallow your pride and do it anyway. Nothing conveys true customer interest like cold hard cash.

Mistake #2: Misunderstanding the MVP

The mistake: A minimum viable product (MVP) is the smallest possible solution to your customer’s problem that they would be willing to use. We made the common mistakes of trying to make our MVP too comprehensive and too perfect, and waiting way too long to get it into the hands of customers.

The consequences: Nobody wanted the EHR interfaces we had built for past medical history, surgical history, medications, allergies, and so on. They wanted one unified interface to do the automated history-taking in one place, which is what we ultimately gave them—but only after writing a ton of code we ultimately never used.

Why I made this mistake: Perfectionism.

What to do instead: Make a truly minimal MVP. After doing customer discovery you should have a pretty good idea of what to build, even if it’s different from your original idea. When trying to define your MVP, don’t only ask customers what features they want—ask them what they don’t really need, and what you can save for version 2.

Once you’ve built an MVP, get it into your customer’s hands immediately, and watch them use it. Listen to their feedback. Fix the bugs they inevitably catch. Iterate based on what the customers actually want, not what you think they should want.

Additional notes: In healthcare, you can’t be quite as sloppy and minimal as you can be in less-regulated industries. If you are going to be handling protected health information, you need to comply with all relevant regulations, including HIPAA and HITECH. Luckily, if you are building your application using a major cloud services provider like Amazon, Microsoft, or Google, it is fairly straightforward to configure everything securely. HIPAA compliance is easier to achieve at a small organization than a large one. You can work with firms that specialize in HIPAA compliance to ensure you’ve dotted your i’s and crossed your t’s. Cydoc worked with Eagle Consulting Partners to become HIPAA-compliant before we launched our application for use with real patients.

Mistake #3: Inefficient software development practices

The mistake: When Cydoc first started, the way we developed the software was incredibly inefficient, including rewriting code every time I wanted to see a different variation of some user interface.

The consequences: Wasted time and money, the lifeblood of a startup.

Why I made this mistake: I had never worked at a software company so I didn’t know best practices. Once I started working with professional software engineers, our practices improved significantly.

What to do instead: From the beginning, somebody at your company—whether a cofounder or an early engineering hire—should understand the software development lifecycle and how to manage software projects. Here are a few specific things you should do:

Use wireframes to plan your user interface. Wireframes are visual representations of the user interface and are typically created in design software like Figma. They can be made interactive, so you can click on buttons and menus. It’s quicker to change wireframes than to change user interface code. Plus, wireframes are super useful for customer discovery. You can give your potential customers access to the wireframes and watch what they do. Can they figure out your user interface without being given any verbal instructions? Are they interacting with the product the way you expect? Iterate on the wireframes until you have the simplest possible product customers would use. Only then should you start writing code.

In your version control system (e.g., GitHub, GitLab, Bitbucket), use separate branches for staging and production, and use branches off of staging for new features. Add a linter and automatically enforce coding standards. Add a mandatory pull request template and require detailed documentation with each pull request. Add tests that automatically run on new pull requests. Implement continuous integration (CI) and continuous deployment (CD) pipelines. Use code review approvals with required reviewers before merging. Maintain detailed documentation including comments and READMEs. Keep packages up to date and implement dependency management. Regularly perform technical debt reviews and refactor. Track issues and tasks in a project management system (e.g., Asana, Jira). Use secrets management for environment variables and credentials.

The Cydoc story: years 5 to 7

Our automated history-taking product had been more expensive to develop than I’d anticipated, and I was beginning to doubt whether it would be possible to bootstrap a cutting-edge AI-native EHR. I thought the government would be a good source of funding. I applied for two NIH SBIR grants, but these grants were rejected for being excessively ambitious and failing to convince reviewers it would be possible to supplant Epic.

We explored many different techniques for finding and acquiring customers. I hired a health tech marketer who created an inbound marketing strategy. With her guidance, I started a Cydoc blog, updated our website to improve its visibility to search engines (SEO), appeared on multiple podcasts, and exhibited at multiple conferences. At one conference, there was so much mold in the exhibit hall that when I opened my mouth to answer a doctor’s question, I burst into a fit of uncontrollable coughing and had to run out of the room. None of these activities yielded any customers.

We switched to outbound marketing. I hired salespeople. We sent thousands of emails and made hundreds of phone calls. I messaged doctors over Facebook and LinkedIn and brought lunch to medical practices. I sent snail mail pamphlets and tried social media ads. Doing all this taught me two things: sales and marketing are hard, and also, I don’t enjoy them.

Through what felt like herculean sales efforts, Cydoc expanded to four paying customers: a family medicine practice, a telemedicine urgent care, an endocrinology practice, and a psychology practice. The urgent care adored our product: “We love it,” “I feel like it saves me a solid 20 minutes per person,” “The questions are really good,” etc. The psychology practice paid for significant customization that evolved into a new product, psychology report generation. They told us that they had fifty clinicians, so we did custom work for them at a loss, chasing the promise of a $5,000/month contract.

I tried to find a cofounder to take over sales and marketing. But even though I spent a significant number of hours talking with many people in and out of my network, I couldn’t find anyone with the right background who was currently looking for a job and could afford to start working for equity rather than cash.

I spoke with hundreds of doctors to demo and refine Cydoc’s platform. I heard from many doctors that they really wanted an AI scribe, which listens to visits, transcribes the conversation, and generates notes from the patient-doctor conversations. I applied for a $50k NC IDEA SEED grant and was awarded this grant in late 2025 to add an AI scribe to Cydoc’s platform. Cydoc had $27,900 in revenue during 2024, $4,200 from subscriptions and $23,700 from the psychology report generation customization. I optimistically viewed this as a 100x improvement from the previous year’s $190 and envisioned us somehow 100x-ing again in 2025.

In the first five months of 2025, with funds from NC IDEA, we added an AI scribe to our platform. From one angle, everything looked promising. We had a patented B2B SaaS health AI software platform including web, iOS, and Android applications. Our automated history-taking was 100% accurate, computationally efficient, and clinically effective, leveraging a proprietary patented knowledge graph, sophisticated graph traversal algorithms, dynamic user interface generation, and a graph expansion process that allowed us to add an entire specialty’s worth of questions in only a couple of hours, with no additional coding required. The automated history-taking saved clinicians over 10 minutes per visit. Our AI scribe, built using Claude and Deepgram, enabled recording and processing clinical conversations into notes to save additional time. The psychology report generation feature generated highly accurate, multi-page psychology reports by anchoring large language models in knowledge graphs. The platform was HIPAA-compliant and customizable. We had customers. We had revenue.

But all was not well.

We lost the urgent care telemedicine customer. They liked our product so much they implemented a narrower version of its key urgent-care-specific features in their own custom app.

We lost the endocrinology customer. The office manager was vehemently opposed to changing the check-in workflow, and apparently they hadn’t been using the product that often in spite of paying for it.

The family medicine customer physically moved locations and in doing so changed their front desk staff, and the new front desk staff didn’t want to bother with the Cydoc QR code. Although they stayed subscribed, they weren’t using the product any more.

The psychology customer faced insurance reimbursement issues and had to stop paying us for a few months until they resolved their cash flow issues. Once they started paying us again, we finished their product. The psychologist could enter answers to 200+ questions, and our system generated a 100% factually accurate, grammatically perfect, 4-to-5-page psychology report with the exact phrasing and formatting they’d requested. Unfortunately, they told us they couldn’t subscribe until we added more features beyond the original scope. I told the practice we were not going to add features based on “theoretical utility.” We needed five of their psychologists to use the product in the next two weeks and give us feedback based on real-world use. The practice owner informed me that they didn’t have five psychologists. I said, “But didn’t you tell me last year that your practice has fifty clinicians?” The owner replied, “Yes, but 47 of them are therapists who won’t be using this particular product.” I felt punched in the gut. We’d sacrificed months of work at a loss building a custom product for an imaginary $5,000/month contract.

Even worse, I realized our business model was broken. Doctors in the small practices we had been targeting wanted to pay fewer than $100 per month for our product. Now that we’d added the AI scribe, the hosting and AI costs for our platform had gone up to about $70 per doctor. To survive we needed to integrate with EHRs, but a single EHR integration costs around $4,000 to $6,000. We couldn’t afford access to the proprietary sales databases specifying which EHRs different practices used, and our manual outbound sales efforts had not been able to identify a large number of practices on the same EHR, so almost every single one of our potential customers would need their own EHR integration. I knew a founder of another startup who had done 14 separate EHR integrations already for his prototype. With revenue only $30 above hosting costs, and $4,000 to $6,000 per EHR integration, it would take 11 years per practice just to break even, not even factoring in ongoing personnel costs.

A major personal health event during this period also reduced my availability and highlighted how we had not sufficiently distributed leadership and decision-making. (Working on a startup from a hospital bed is not a good idea.)

I began to consider selling Cydoc to an EHR company, but after multiple conversations, I was unable to sell due to insufficient recurring revenue. I kept having moments late at night, right before falling asleep, where I thought, “Cydoc is dead. I have to shut it down.” But on principle, I don’t make any big life decisions late at night. I’d inevitably wake up the next morning filled with ideas for how I could save the company and I’d get back to work.

Then came Friday, August 22, 2025. In the middle of the afternoon, I had the same thought: “Cydoc is dead. I have to shut it down.” Daylight poured in through the window. I sat at my desk for a while. I always thought of that desk as my “CEO desk” because even though I found it at a local thrift store, it always had an aura of officiality about it, with its dark wood and clawed feet.

I had spent all my savings on Cydoc. I had worked on Cydoc without pay for years, instead of getting an extra paper during graduate school, instead of doing residency and getting a medical license, instead of taking some high-paying, intellectually stimulating AI job. To avoid personal bankruptcy, I’d had to squeeze in a few hours of consulting here and there, while I focused my heart and soul on Cydoc. I had truly believed we would change the world with our AI-native EHR. Even worse, I’d looped my family and friends into it by asking them to invest. But the business model was broken, and we didn’t have enough time or capital to fix it.

I spent the next few hours of that August afternoon writing a multi-paragraph analysis to share with the people who had invested in Cydoc, analyzing what had gone well and what I’d done wrong. Then I sent an email to the family, friends, and physicians who had invested and told them I was closing the company. I updated my LinkedIn to put an “end date” on Cydoc.

A few days later, I took down all of the hosting, which as a technical person felt like burning down my own house. We licensed our codebase and IP to another startup. I toasted Cydoc with sparkling cider and buried one of the Cydoc promotional pens in the yard. Although the legal shutdown process dragged on for weeks afterwards, to me, Cydoc died on that afternoon in August when I told the world it was over.

Mistake #4: Inadequate sales and marketing

The mistake: I grossly underestimated the vital importance of sales and marketing. I failed to find a rockstar cofounder who could own sales and marketing. I didn’t allocate enough budget, time, or energy to this vital part of the business.

Initially, I thought that the small research study we did showing massive time savings with automated history taking would be enough for customers to come to us. Then I thought that putting up a website would be enough for customers to come to us. When customers did not materialize out of thin air, I began trying more active strategies to find customers, like making phone calls and sending emails. We found one customer through a cold call, one through a cold email, one through a very warm intro (the endocrinologist: he was my husband’s uncle), and one via a consulting network. There wasn’t one particular method that we ever got right, such that we could count on it for a steady flow of customers.

In retrospect, I now realize that the main reason I proposed spending the NC IDEA grant on an AI scribe was because I thought that if we added an AI scribe to our product, sales and marketing would suddenly become easy. This did not happen. If anything, adding the AI scribe made conversations with customers harder, because now we had two things we were offering instead of one. I was trying to transform something that was hard for me—sales and marketing—into something that was easy for me—adding more features to our software.

At the time I shut Cydoc down, I believed that the majority of doctors did not want automated history-taking. A couple tech-forward practices had loved what we built, but I had subsequently talked to scores of clinicians who reacted to our automated history-taking as if it were a threat. It was only while writing this book that I realized this was probably at least in part a marketing error. Some of Cydoc’s competitors, who offer similar automated history-taking technology, are doing well, and if you look at their websites, you don’t see the phrase “automated history-taking” anywhere. Instead, they use phrases like, “automates patient conversations,” “streamlines intake,” “delivers complete clinical notes,” “automatically drafts clinical note text,” and “intake forms with a clinical twist” followed by quotes from doctors who love their product.

The consequences: Not enough customers → Not enough revenue → Dead company. This is the single biggest mistake I made on Cydoc.

Why I made this mistake: For far too long, I was (unconsciously) using “build it and they will come,” as my sales and marketing strategy. This mistake is the same as, “my idea is so awesome it’ll go viral,” or “my idea will spread by word-of-mouth,” or “we put up a website where people can sign up, which means they will sign up.” I have noticed that doctors, engineers, and other technical people are especially susceptible to this mistake. Once I realized we needed some sales and marketing, I tried to do them myself, underestimating the amount of knowledge, skill, and experience required to do them well. I failed to find a cofounder to own this space.

What to do instead: Make sure that one of your cofounders is an expert in health tech sales and marketing. And don’t try to “solve” sales or marketing with more software features.

Mistake #5: Not having the right cofounders

The mistake: I ran Cydoc as a solo founder.

The consequences: Not enough sales/marketing expertise → Not enough customers → Not enough revenue → Dead company, as above. Also: Couldn’t raise money from institutional investors since they generally only invest in teams with multiple founders → Bootstrapping → Always tight on cash → Stuck in a bind over things that wouldn’t be a big deal to better-funded companies, like building EHR integrations.

Why I made this mistake: I thought that with enough hard work, I could do it all, and be good at it all. For seven years, although my title was CEO, but I was effectively working as the CEO, CTO, and CRO at the same time. I wore the CEO hat and set the vision, pitched to investors, wrote grants, managed finances, managed customer relationships, recruited and hired people, and talked about the company for podcasts and news articles. I wore the CTO hat and decided on the product’s technical specifications and features, worked closely with designers to create the UI/UX down to the level of individual buttons and icons, led the engineering team, set our coding standards, opened bug reports, reviewed and tested all the pull requests, designed our AI strategy, invented our knowledge graph automated history-taking system, and wrote a bunch of code. I wore the CRO hat and worked on branding, market positioning, advertising, pricing, lead generation, and sales strategy, including cold calling, cold emailing, in-person lunches, conferences, social media networking, blogging, and managing sales and marketing hires. On top of this I did all the other random “startup stuff.” For example, on the legal side, I worked closely with lawyers on our terms of service, HIPAA compliance, trademark application, and patent applications including creating over a hundred pages of technical descriptions and figures. This isn’t to say I was working alone—far from it. I had amazing team members who worked on engineering, sales, marketing, and legal with me. But they didn’t “own” any large domains of the business. What suffered most from me overextending myself was our sales and marketing, because I didn’t enjoy it. Choosing the wrong cofounders will kill your business, but so will choosing none at all.

What to do instead: Find cofounders with complementary skills to your own. I now believe that the minimum number of cofounders for a tech company is two: a CEO who is business/sales/marketing oriented, and a CTO who is technical.

For health tech specifically, you do also need clinical expertise. You can have a clinical co-founder, create a robust group of clinical advisors, and/or have an early clinical hire.

Mistake #6: Not integrating with EHRs

This mistake is why things went south with our family medicine and endocrinology customers.

The mistake: I put my company into a trap. We didn’t want to integrate with other EHRs because it was our mission to become an EHR, so spending money on EHR integration felt like a waste of time and a way to give our future competitors a leg up. But by refusing to integrate, we made adoption too difficult. Behavior change is hard. The decision not to prioritize EHR integration was a fatal mistake.

The consequences: Customers hard a hard time using our standalone product → Not using the product means no benefits → No benefits mean unsubscribing → Lost customers.

Why I made this mistake: I underestimated the difficulty of behavior change.

What to do instead: Unless your company already offers an EHR, integrate your health AI innovation into EHRs. Which EHRs you choose depends on your target customers:

  • If you are targeting health systems, focus on the big EHRs that dominate health systems: Epic, Oracle Cerner, and MEDITECH. You can start with the biggest one, Epic, and have plenty of potential customers. But be warned—deployments of Epic are different, so each Epic integration can be like a separate EHR integration depending on what your product does.
  • If you are targeting private practices in a non-specialty-specific manner, you can focus on the top outpatient EHRs—Epic and Oracle Cerner again, plus athenahealth, NexGen Healthcare, ModMed, and more. (I specifically didn’t list eClinicalWorks because even though it’s a top outpatient EHR, their API limits what integrations are possible.)
  • If you are targeting private practices within a specific specialty, you can pursue specialty-specific EHR integrations.

Sales databases like Definitive Healthcare are expensive but can quickly inform you of which practices use which EHRs.

Mistake #7: Not having a real technological moat

This mistake is why things went south with our urgent care customer.

The mistake: Having a technological moat means you have a sustainable competitive advantage because it’s difficult for competitors to replicate or surpass your proprietary technology. My mistake was thinking that we had a technological moat because we had patents and because it would be difficult for others to replicate all of our technology. We had sophisticated code for knowledge graph traversal and dynamically generating user interfaces based on arbitrary pieces of the knowledge graph, and it would’ve been difficult for others to copy all this—but they didn’t need to copy it all to copy the heart of what we were doing. The urgent care telemedicine practice created a pared-down version of our system by hardcoding our questions into a traditional form interface with extra text generation logic behind the scenes. Sure, their implementation wasn’t immediately extensible to other specialties, but it didn’t have to be. Cydoc’s “moat” was more of a rain puddle.

The consequences: Lost customer.

Why I made this mistake: Lack of understanding of a true technological moat.

What to do instead: Have a real technological moat, or have some other moats:  

  • Cost moat: Economies of scale that let you offer lower prices.
  • Network effects moat: Product value increases as more users join—in the context of health AI, maybe you get more data as you grow and this helps you refine your model.
  • Regulatory moat: You’ve achieved a hard-to-achieve regulatory approval.
  • Distribution moat: You have exclusive relationships or infrastructure that’s hard to replicate.
  • Customer switching moat: It’s hard for customers to switch away from you. EHRs love using this moat.
  • Cultural moat: A unique company culture that leads to superior results. For example, you offer amazing customer service or tech support.

Additional note: Patents aren’t worth much if you are unable or unwilling to enforce them.

Mistake #8: Falling into a custom development trap with a bad contract

This mistake is why things went south with our psychology customer.

The mistake: I thought the psychology practice, with its 50 clinicians, was going to “save Cydoc” with a $5,000/month subscription. The subscription never happened.

The consequences: Distraction from our main focus, with time and money sunk into a product that turned out to be more of a hobby for the practice owner than a platform they were going to use.

Why I made this mistake: I had heard some inspiring stories about bootstrapped software companies that got started by doing custom development work.

What to do instead: If you do decide to create custom features for your clients, make sure you have a watertight contract. At a minimum:

  • The customer covers all of the actual costs of the software development, meaning you invoice them for the actual cost. I’m not a fan of fixed-price contracts for software because even if you dramatically overestimate, it’s too easy for scope creep to turn a seemingly simple project into a nightmare. Non-technical clinicians may insist on “slight” changes that seem minor to them but are difficult to implement.
  • If you are a SaaS business, the customer should agree to subscribe for a certain price by a certain date, or once you implement a specific, limited feature set.

Mistake #9: Failing to identify a broken business model in time to fix it

The mistake: By the time I realized our business model was broken, we didn’t have enough capital to fix it.

A business model is, at the most abstract level, how a company creates, delivers, and captures value. But in the real world, a functioning business model is the opposite of abstract—it is incredibly specific, because the devil is in the details. A functioning business model involves a complex interplay between multiple facets of the business:

  • For creating value, what healthcare problem are you solving, and what are your development costs?
  • For delivering value, how do you reach and serve customers? What’s your target market, what are your distribution channels, and what’s your sales and marketing strategy?
  • For capturing value, how do you make money? What’s your pricing strategy and what are your revenue streams?

Why I made this mistake: Avoiding cold harsh reality and instead fixating on band-aids, like distracting custom development, or imagining that adding an AI scribe feature would make sales easy. 

What to do instead: Schedule a regular check-in at least once a quarter where you think critically about the nuts and bolts of your business model and work through the math. Also talk about your business model with your advisors and ask them to find holes in it. Sometimes it is easier for outsiders to see problems that you may not be able or willing to see as an insider.

Additional Notes:

Hindsight is 20/20: I will now indulge some “what ifs,” and imagine some ways I might have saved Cydoc if I had realized one year earlier that our core business model was broken.

  • Strategy 1: Keep the same target customers, small-to-midsize urgent care private practices, and find a cofounder who is really good at cost-effective marketing and sales to reach these customers—perhaps leveraging social media marketing, something I suspect one of our competitors was doing very well. Raise prices slightly, to around $170/seat/month, and get into the “startup program” for the speech-to-text service we were using to lower hosting costs. Leverage our grant funding for 2 to 3 initial EHR integrations, and for sales and marketing. Buy a sales database to aggressively target additional customers on the integrated EHRs.
  • Strategy 2: Change our target customer to mid-to-large private practices, and get someone onboard who is good at marketing and sales to reach these bigger customers. Raise prices to enterprise levels. Integrate specifically with Epic.

On capitalism: When I first started working on Cydoc, I did not understand that the point of a startup in a capitalist society is to charge more for the product than it costs to host or make. My whole life I’d been surrounded by people who griped that if a plastic toy costs only 20 cents to make then why isn’t it sold for 20 cents? If a car costs $10k to manufacture, why isn’t it sold for $10k? I thought to myself, I’m going to be the first person to run a business where I sell things for a fair price. I’ll price the software at what it costs to run! Then it’ll be so good and so cheap, everyone will be happy and love it, and I’ll change the world, and it’s fine if I don’t make much money doing it.

I soon realized that in order to have a viable business, one that doesn’t collapse and fail, you need to at a minimum charge enough to also sustain your people. If you’re a software company, this means you can’t just charge the hosting costs. You have to factor in all kinds of other costs, like software engineers, tech support, salespeople, marketers, legal fees, accounting fees, and so on. If you don’t factor in these costs, you will perpetually lose money.

Yet another thing it took me far too long to realize is that there’s often an additional layer to pricing: that whole thing in capitalism where the capitalist profits off of the labor of others. Elon Musk is a quintessential capitalist. Has he, as a solitary individual, created billions of dollars in value? Not in isolation. He “owns” the labor of many other capable people, and that’s why his net worth is so high. So, there is often another bump in the price, to give the person at the top extra money just because. This final bump is the one regular people get the most upset about, and it’s the one that institutional investors love most of all. They are venture capitalists, after all.

On pricing: Pricing, as a core component of a business model, is tricky because the customer needs to have enough money to pay your price, and they need to be willing to pay your price. If either of these two requirements isn’t met, your pricing doesn’t work.

Summary of my startup mistakes

That concludes my analysis of the key mistakes I made when running Cydoc:

  • Mistake #1: Delayed and minimal customer discovery
  • Mistake #2: Misunderstanding the MVP
  • Mistake #3: Inefficient software development practices
  • Mistake #4: Inadequate sales and marketing
  • Mistake #5: Not having the right cofounders
  • Mistake #6: Not integrating with EHRs
  • Mistake #7: Not having a real technological moat
  • Mistake #8: Falling into the custom development trap with a bad contract
  • Mistake #9: Failing to identify a broken business model in time to fix it

These mistakes are interconnected. Our issues with customer discovery and poor initial software development practices contributed to making the wrong MVP. Running the company as a solo founder without a sales and marketing cofounder led to our inadequate sales and marketing infrastructure. The custom development trap helped obscure the broken business model until it was too late to fix it. Not having the right cofounders prevented me from raising enough capital to tackle our core mission of an AI-native EHR head-on, an approach that would have sidestepped the EHR integration issue entirely.

Additional startup mistakes reported by other founders

I am grateful that we got as far as we did at Cydoc. It was far enough to have a positive impact on our customers, and to learn some important lessons. I am also grateful that I didn’t make every single possible mistake. Founders of other tech startups have described mistakes they made working on their companies. I’ve aggregated some of these additional mistakes here:

Early Mistakes

  • Mistake #10: Neglecting legal and financial fundamentals: Some startups skip proper incorporation, founder agreements, IP assignment agreements, or financial tracking, which creates landmines that explode later.
  • Mistake #11: Cofounder conflicts and unclear roles: If founders avoid discussing equity splits, decision-making authority, responsibilities, company vision, and values upfront, this can create resentment, paralysis, and destructive drama.
  • Mistake #12: Raising too much money too early: Excessive funding can lead to wasteful spending or inflated valuations that are hard to grow into, and founders can give up too much equity and control too early. (As someone who bootstrapped, I think I would enjoy having the opportunity to make this mistake.)

Product Mistakes

  • Mistake #13: Copying competitors instead of innovating: Startups that play catch-up with features are always behind and undifferentiated.
  • Mistake #14: Ignoring customer feedback: Dismissing criticism or complaints as users “not getting it” prevents improvement and damages customer relationships.
  • Mistake #15: Letting technical debt accumulate: Efficiency is critical, but it’s important not to sacrifice too much quality in order to ship faster. Never paying down technical debt creates an unmaintainable codebase for which adding features or fixing bugs takes forever.

Mistake Potpourri

  • Mistake #16: Ignoring unit economics: Some startups focus exclusively on growth even while they are losing money on each customer, which is a recipe for disaster. (Certain generative AI companies appear to be doing this by losing money on both free and paid subscriptions while trying to figure out a sustainable business model.)
  • Mistake #17: Scaling too quickly: Expanding to new markets, building infrastructure, or growing the team before achieving product-market fit shortens runway and dilutes focus.
  • Mistake #18: Running out of money: Founders can underestimate how long fundraising takes and overestimate their runway.
  • Mistake #19: Building for everyone: Trying to appeal to every possible customer often means appealing to nobody strongly enough.
  • Mistake #20: Focusing on features instead of benefits: Marketing that focuses too much on technological features can miss the mark, because customers only care about solutions to their problems.
  • Mistake #21: Micromanaging instead of empowering: Founders who can’t delegate become bottlenecks that slow everything down.
  • Mistake #22: Ignoring mental and physical health: Burnout damages decision-making ability, creativity, and relationships.

Medical Devices

  • Mistake #23: Underestimating regulatory complexity: FDA approval is a strategic process requiring 18 to 36 months and significant resources, and if founders underestimate regulatory challenges, they might fail to get critical approvals in time.
  • Mistake #24: Ignoring reimbursement strategy: Building a great device is worthless if nobody will pay for it. Startups may discover too late that existing billing codes don’t cover their medical device, or that health economics don’t justify adoption.
  • Mistake #25: Underestimating manufacturing complexity: Founders may prototype with manufacturers that don’t have the proper certification needed for medical devices. Transitioning from hand-built prototypes to validated manufacturing processes is expensive and time-consuming and may delay or prevent launch.

Keys to success

Flipping the mistakes around, we can create a list of keys to success for health tech startups:

  • Key #1: Early and thorough customer discovery.
  • Key #2: Customer-informed, truly minimal MVP that reaches customers ASAP.
  • Key #3: Professional software development practices.
  • Key #4: Robust, expert-led sales and marketing.
  • Key #5: Wisely chosen cofounders with complementary, non-redundant skill sets. The minimalist founder set is a CEO for business/sales/marketing, and a CTO for engineering/product.
  • Key #6: EHR integration to enable seamless adoption.
  • Key #7: Real moats.
  • Key #8: Be cautious about custom development. If you do pursue it, use a watertight contract with clear expectations up front.
  • Key #9: Mercilessly search for holes in your business model at least once a quarter, and ask outside advisors to do so as well.
  • Key #10: Complete your legal and financial fundamentals at the beginning.
  • Key #11: Codify cofounder roles/equity and company vision/values up front.
  • Key #12: Raise only the minimum amount of money you need to reach the next milestone.
  • Key #13: Focus on your unique value proposition and what you can do better than anyone else. Be a leader, not a follower.
  • Key #14: Take customer feedback seriously.
  • Key #15: Schedule regular refactoring and infrastructure improvements.
  • Key #16: Ensure profitable unit economics.
  • Key #17: Stay lean until revenue and a healthy business model justify expansion.
  • Key #18: Allow plenty of time for fundraising and estimate runway conservatively.
  • Key #19: Define your target market narrowly and precisely, for focused product development and efficient marketing. After dominating an initial niche, it’s possible to expand into adjacent markets, a strategy covered in the book Crossing the Chasm by Geoffrey A. Moore.
  • Key #20: Marketing should emphasize outcomes and value, not technical specifications. Speak the customer’s language.
  • Key #21: Hire people smarter than you and trust them to execute. A founder’s job is to set direction, not approve every little decision.
  • Key #22: Take care of yourself. The startup marathon requires sustainable pacing, not constant sprinting.

Medical Devices:

  • Key #23: Engage regulatory consultants early on. Regulatory requirements should be built into the initial design specifications.
  • Key #24: The reimbursement strategy should be investigated alongside device development, not after.
  • Key #25: Work with certified manufacturers and leverage validated manufacturing processes.

Closing thoughts

Building a startup was a highly rewarding experience, even though the company ultimately shut down. I learned so much about what it takes to make health AI ideas into reality. I hope that the lessons from this article will help you make your next venture an incredible success.

What’s next

One project I’m very excited to be working on now is a book on health AI, bridging healthcare, artificial intelligence, and business. If you’d like to be the first to hear about it, and receive a free list of my favorite health AI resources, you are welcome to sign up here.