Most practice leaders hit a point where a technology problem starts to feel personal. The EHR adds three clicks to a task that already took too long. The scheduling platform still can't handle the rule your front desk explains 20 times a day. You pay another annual interface fee for two systems that somehow still require someone to retype information from one screen into the other. 

Then, after one particularly bad Tuesday, the thought arrives: “How hard would it be to just build this myself?” 

That question used to answer itself. It doesn't anymore. 

“Vibe coding” — describing what you want in plain language and letting a generative AI tool write the code — has put working software within reach of people who would never call themselves developers. AI coding tools can shorten the path from spotting a broken workflow to testing a working prototype. 

A physician recently posted on Reddit about building his own EHR with Cursor and ChatGPT, and the replies filled up with others doing the same thing:  

• A neurologist writing a local AI scribe because the commercial ones document in a style he doesn't like 
• Another physician building a web app that sits on top of his EHR and uses its APIs to automate practice-management work.  

The thread also filled up with warnings about security, compliance, and the obligations that come with becoming your own software vendor. 

Practice leaders know where the real problems are, and vendors often have little incentive to solve the narrow ones. But “we built an app” covers enormous ground — from a staff task tracker to software holding the legal medical record — and the risks and requirements change sharply as you move along that range. 

More than 4 in 10 practices have vibe-coded a new app or tool (or tried) 

A Sept. 22, 2026, MGMA Stat poll asked medical group leaders if their practice has built its own app or workflow tool in-house using AI. About 34% said "yes," while another 8% said they had tried but did not launch the project. About 54% said "no" and 10% were unsure. The poll had 228 applicable responses. 

That puts homegrown AI tools well beyond the purely experimental stage, even if most medical groups still have not built one. The 10% who were unsure also raises a governance question: Leaders may not always have full visibility into tools being created or tested inside their organizations. The poll cannot tell us whether that is happening, but as AI-assisted development gets easier, practices may need clearer rules for when an experiment becomes something the organization needs to know about and govern. 

What you told us 

Respondents who have built their own tools described a wide range of projects, but most were aimed at familiar operational problems rather than replacing a core clinical system. Examples included scheduling and appointment management, prior authorization and denial work, internal dashboards, inventory management, policy and workflow development, call handling, recalls and staff tracking. 

The projects also varied widely in risk. Some were essentially internal productivity tools, such as dashboards, workflow documentation and policy development. Others moved closer to protected health information or clinical operations, including charting support, biologic-ordering workflows, coding and audit guidance, and patient-facing tools. That range reinforces why “we built an app” is not a useful risk category by itself: what the tool can see, change or generate matters much more. 

The small group that tried but did not launch a tool did not point to one dominant reason. Responses included regulatory concerns, projects being put on hold and one effort to create a central home for policies, procedures and forms that became too labor intensive.  

Among groups that have not tried building their own tool, the wish list looked a lot like the projects already underway elsewhere. Prior authorization was one of the most frequently mentioned needs, along with scheduling, revenue cycle and denial work, insurance verification, documentation, patient intake and other manual administrative tasks. 

The overlap is notable: Practices building their own tools and those that have not started often point to the same pain points: repetitive work, fragmented workflows and gaps between existing systems. The difference seems to be whether someone in the organization has the time, confidence and permission to try building around it. 

It's also useful to note that it's also not a question of whether practices outright reject using AI, in-house or via a vendor: our Aug. 4, 2026, MGMA Stat poll found AI plays some role in patient visits at 83% of medical groups. 

From clever shortcut to software owner 

Building your own tools is not inherently reckless. Practices run on highly specific workflows that no vendor has a business case to fix, and a small custom tool can automate a spreadsheet, organize a work queue, reconcile two lists, clean up a handoff or strip repetitive steps out of an existing process. AI shortens the distance between the person who understands the problem and something that demonstrates a fix. 

There is a wide gap between building a staff task tracker and replacing your EHR. As these tools become easier to create, leaders need to move beyond “can we build it?” to the harder question: What will happen if it works and your practice starts depending on it? Here are 10 things to settle before an experiment becomes production software. 

Before you write any code 

1. Put the project on a risk ladder. Start with what the tool can see and what it can do. Does it touch no patient information at all? Does it read PHI? Write information back into the EHR? Generate clinical documentation? Recommend something that could affect care? 

The higher the rung, the more governance, security, testing and legal review the project needs. A vacation-request tracker and a tool that drafts clinical content should not clear the same approval process. Document the risk level at the start and reassess it whenever someone adds a feature. 

2. Follow the data, including into the coding tool. “It’s local” does not make it compliant, and “it’s in the cloud” doesn't automatically make something unsafe. A homegrown tool that handles ePHI belongs in your practice's HIPAA security risk analysis (SRA). Cloud services can handle ePHI when HIPAA requirements are met, including a business associate agreement (BAA) where required. HHS says a cloud provider that stores or processes ePHI on a practice's behalf can still be a business associate even when the data is encrypted and the provider does not hold the encryption key. 

Map the full path: prompts, model providers, databases, logs, backups, APIs, analytics, and error reporting. Include the development environment itself. Real patient records pasted into a coding assistant to debug a display problem are still PHI. So is a database dump uploaded to help the model understand your system. Do not assume a consumer AI account includes a BAA; verify the product, account tier, and terms before using it with PHI. 

HHS has also proposed significantly tougher Security Rule requirements, including stronger encryption, multifactor authentication, and security testing. Those changes are not yet final, but they point toward tighter expectations for organizations handling ePHI. 

3. Remember that AI-generated code is still code. AI can make working software appear remarkably fast. It does not remove software engineering. Someone still needs to think about authentication, permissions, dependencies, patching, vulnerabilities, backups, recovery and testing. 

Two specifics for anyone building with an AI assistant. First, AI coding assistants can also suggest software packages that do not exist. Attackers have exploited that behavior by registering those package names, so verify every dependency before adding it to the project. Second, the faster code gets written, the easier it is to end up with a system nobody fully understands, including the person who built it. Ask your builder to explain what happens when a given function fails. If the answer is “I’d ask ChatGPT,” that's quite telling. 

4. Decide who owns it before it becomes important. One employee’s clever Friday-afternoon project can become an organizational dependency by spring. Who owns the source code? Who holds the passwords and API keys? Who approves changes? Who fixes it if the builder leaves, and who decides whether a new version is safe to install? 

Put ownership in writing, particularly when  the builder is a physician-owner or a contractor rather than an employee — ownership of code is not automatic, and it is a bad thing to litigate later. A January 2026 MGMA Stat poll found 42% of medical group leaders said their organization either had AI governance or a formal AI-use policy (20%) or was developing one (22%). Building your own software makes those questions more urgent, not less. 

5. Make failure cheap before you make the tool important. Prototype with synthetic or properly de-identified data. Start with one narrow workflow. Give the tool read-only access before it writes into anything. Keep the old process running until the new one has earned its place. 

And decide in advance what would make you shut it down. A failed prototype is cheap learning. A failed production system at 8 a.m. Monday is an operations problem with patients in the waiting room. 

Before it touches a patient chart 

6. Assume you're creating a legal record, not a file. If your tool creates or stores information that becomes part of the patient record, the practice needs a plan for access, amendments, retention, auditability, and legal production. Those requirements vary depending on the record and applicable federal rules. Then there's the part nobody plans for. State retention laws typically require records to be kept for years after the last encounter, and longer for minors. Your homegrown tool must outlive the enthusiasm that created it. If the builder leaves in 2028 and the tool is retired in 2029, can someone still produce a legible, authenticated 2027 chart in 2035? Have that answer before go-live, not after. 

7. Know what certification you might be walking away from. If your clinicians are required to report the MIPS Promoting Interoperability category, they must use certified EHR technology (CEHRT). CMS automatically reweights that category for certain clinicians and groups, including qualifying small practices, ASC-based, and non-patient-facing clinicians and groups, so check your organization's status before assuming the requirement applies. 

Health IT you build yourself does not become certified simply because it connects to a certified EHR. ONC does recognize self-developed health IT, but certification is a formal process involving testing through authorized bodies and ongoing certification requirements. Ultimately, the question hinges on whether your practices is relying on that tool for capabilities that must be certified under a federal program in which you participate. 

Also know: ONC treats a healthcare provider that develops health IT for its own use differently from an organization that offers that technology to others. Before handing your homegrown tool to another practice — especially if it is certified health IT — understand how that could change your obligations.  

8. Test for clinical consequences, not just working buttons. Ordinary software fails by breaking. Healthcare software can run exactly as written and still produce the wrong clinical result — a summary that drops the allergy, an extraction that grabs the wrong date, a draft note that reads fluently and says something untrue. 

Anything that summarizes, extracts clinical information, drafts notes or influences a decision needs validation against realistic cases and a defined human review step. “It worked when I tried it” is not a test. 

Tools that begin recommending clinical actions can also raise FDA questions. FDA updated its clinical decision support guidance in January 2026, including criteria around whether clinicians can independently review the basis for a recommendation. Practices moving into that territory should get specialized regulatory guidance. 

9. Ask what it has to connect to, and what happens when it can’t. A homegrown tool rarely stays alone. Eventually someone wants it talking to the EHR, the practice management system, the lab, the clearinghouse, the scheduling platform, a payer portal or the pharmacy network. That’s where a weekend project meets healthcare interoperability. The Reddit thread reaches exactly this point: builders begin asking about EHR APIs, Surescripts access, audits and other infrastructure that turns a homegrown tool into a much larger undertaking. 

Interoperability also brings compliance obligations. Information blocking rules apply to healthcare providers, not just vendors. 

10. Call your insurance broker before go-live. Do not assume your cyber or professional liability coverage extends to software the practice develops in-house. Before go-live, ask your broker specifically whether the policy would respond to a breach or patient-harm claim involving a homegrown tool. 

Price ownership, not creation 

The appeal of vibe coding is that version 0.1 can feel almost free. Year five will not. 

Price the maintenance, the infrastructure, the security reviews, the integrations, the testing, the monitoring, the outside expertise when something breaks, the rework when a regulation changes and the staff hours spent supporting a tool that used to be somebody's hobby. Commercial software is expensive partly because ownership carries costs that stay invisible while someone is building the first version at night. 

Build where your knowledge gives you an advantage 

None of this is an argument against experimenting. Practice leaders may be unusually well positioned to spot opportunities vendors overlook. They know where staff invent workarounds, which spreadsheets secretly run the organization, where information gets entered twice, and how a five-minute task became a 20-minute workflow. AI now gives more of those leaders a way to test whether they can fix it. 

The discipline is knowing where experimentation ends and production software begins. For many practices, the lower rungs may be the best place to start. Respondents in this poll described tools for inventory management, scheduling, internal dashboards, policies and other operational workflows — areas where a mistake may be easier to detect and reverse than in software creating or changing clinical information. 

You probably don't want to become your own EHR vendor, but the next useful tool in your practice may not come from an EHR vendor, either. It might come from the person who finally got tired enough of the workflow to build something better. 

Suggested resources 

• AI for Medical Practices — MGMA's collection of current AI articles, podcasts and education. 
• AI governance in medical group practices: Rules for the humans in the loop — approval, accountability, data rules and human oversight.  
• AI governance and compliance: How medical groups can adopt AI without inheriting unmanaged risk  
• EHR and PM workarounds reveal the hidden cost of broken workflows — the problem that starts most of these projects.  
• Cybersecurity in Medical Practices Playbook  
• Beyond the hype: Practical AI applications that improve access, capacity, and revenue