Case Study: How Pillars of Wellness Built Its Own Business Software, Without a Single Engineer

An Indiana behavioral health group of more than 100 clinicians used AI to build 32 connected tools running on one shared database, then drew a hard line about what AI would never be allowed to decide on its own.

Written by Mary Dougherty (TechPoint) and Ashley Michalski (Pillars of Wellness)

Pillars of Wellness is a behavioral health group of more than 100 clinicians across five offices in Northwest Indiana and Indianapolis, plus telehealth. Co-founders Dr. Shaun Wehle and Amber Wehle founded it in 2017 and grew it from six employees in 2019, and it runs leaner than most practices its size: a single biller handles claims for the entire clinical staff. It is not a technology company, and none of the people who built its software were trained engineers.

Three people built the software the company now runs on. Dr. Shaun Wehle, a psychologist with a background in psychological assessment, spent years watching where the practice’s daily operations broke down and knew exactly which problems were worth solving. Dr. Ashley Michalski, Chief Operating Officer, also a psychologist, refined the vision and did the hands-on building. Max Zylstra, the practice’s Director of IT, built the infrastructure underneath everything the other two created. Together the three of them built 32 connected tools, called hubs, that all read from and write to the same shared database.

They built it by talking to Claude, an AI assistant from Anthropic, the way you might talk to a capable new hire: describing a problem in plain language, reviewing what came back, and asking for changes until it worked. When a change was ready, the team shipped it, meaning they released it for everyone at the practice to start using right away.

They built it by talking to Claude, an AI assistant from Anthropic, the way you might talk to a capable new hire: describing a problem in plain language, reviewing what came back, and asking for changes until it worked. When a change was ready, the team shipped it, meaning they released it for everyone at the practice to start using right away.

Since the system went live, the team has shipped several updates a day. Once they realized it would become the practice’s own operating system, they wrote one guiding rule directly into the code: AI can check whether something is true, but it can never decide what a licensed clinician should do. That principle, “AI proves, people attest,” now shapes every one of the 32 hubs, and it’s the reason a practice with no engineers on staff trusts the system to run daily operations that touch real client care.

Overview

Before this project, three simple questions that should have had one clear answer instead had three or four different ones, depending on who you asked and which system they checked. Like many growing practices, Pillars was running largely on Google Sheets and an electronic health record (EHR) system that didn’t talk to each other. Is this clinician still accepting new clients? Has this training requirement been met? What is still outstanding on this file? Getting a real answer to these questions meant calling around the office.

Pillars of Wellness built its own operating system across that existing patchwork, hub by hub, using AI as the building tool rather than the decision maker. As a result, questions that used to take a staff member the better part of an hour now surface in minutes, because the answer lives in one shared place instead of three or four. The team then wrote the AI proves, people attest rule directly into the code, spelling out what the software would and would not be trusted to decide on its own.

Here is what that build looks like today:

• More than 100 clinicians across five offices and telehealth, all running on one operating system
• One biller supporting the entire clinical staff
• 32 departmental hubs running on one shared database
• More than 40 features that use AI, and every one of them stops short of making a final decision on its own
• Several small software updates have shipped every working day since the system went live
• Zero client-facing AI, a limit the team has chosen not to cross yet

Industry Context and Business Challenge

Behavioral health practices carry a heavy amount of paperwork and rules for their typically small teams. A single clinician can be governed by federal privacy laws, state-specific licensing boards, insurance credentialing requirements and continuing education rules that are each audited on their own schedule. Pillars of Wellness also provides continuing education itself, which comes with its own set of obligations to track.

None of that work is clinical care. All of it competes with the time clinicians could spend on clinical care.

The usual way a practice grows through that load is to hire administrators in step with clinicians. That works, but it makes every new clinician more expensive and the organization slower. Pillars wanted a different growth curve: add clinicians without adding paperwork, and add sites without adding systems.

Here is what that looked like day to day before the rebuild. Whether a clinician was still accepting new clients might be marked yes in the client intake spreadsheet and no in the EHR, because nobody had gone back to update the spreadsheet. A supervisor checking a clinician’s progress toward independent licensure had to piece it together from continuing education certificates, a credentialing folder and whatever the clinician remembered off the top of their head, if it could be tracked at all. A simple question like what is still outstanding on this file could eat up the better part of an hour, because the answer required checking with three or four different people who each held one piece of it. That wasn’t just time lost; it was time taken from client care.

That pattern is what pushed the team toward a hard question, one that ended up shaping the entire project:

Get that boundary wrong in either direction, and a practice risks either burying clinicians in more paperwork or letting an algorithm make a call that should carry a license behind it. For Pillars of Wellness, getting it right became the center of the project.

AI Implementation Strategy

Rather than hiring a software vendor or spending years saving for a custom build, Pillars of Wellness decided to build the system itself, using AI to do the actual coding. Once the team knew the project would grow into something the whole practice depended on, they settled on one non-negotiable rule and wrote it directly into the software rather than leaving it in a policy binder: AI proves, people attest. If a claim can be checked against real evidence, the system checks it automatically. If the answer depends on a professional judgment that a person’s license is attached to, the system stops, hands the decision to a person and explains why it stopped. That rule is what let the team move fast everywhere else, because they always knew exactly where the line sat. The instinct behind it started in Ashley’s early experiments; it became official policy once everyone could see the platform was here to stay.

The rule itself wasn’t new to the team. Since Paul Meehl’s Clinical Versus Statistical Prediction was published in 1954, psychologists have known that a well-built formula often predicts better than unaided expert judgment. The profession’s answer was never to hand the decision to the formula. In psychological evaluation, test scores inform the decision; the psychologist signs the determination and carries the responsibility for it. Dr. Wehle and Dr. Michalski both came to this project from that tradition, and before AI arrived Pillars was already using algorithmic tools in its own operations, such as a profile-based model for matching clients with clinicians. Meehl and his colleagues went further: clinicians who override a sound formula usually make predictions worse. So, the point of keeping a person in the loop is not that human judgment is more accurate. It is accountability: a licensed person signs the determination and answers for it. AI proves, people attest applies the same structure to an entire company.

Solution and Implementation

Here’s how the system came together, one step at a time.

Phase 1: From a Mac Mini to a Team Effort

It started small, and it started with one person. Shaun tells this part at his own expense. While Ashley was on maternity leave, he bought her a Mac mini, a small desktop computer, so she could experiment with how AI might fit into the practice’s systems. He maintains it was a gift. Ashley doesn’t mind that it was a hint. She started with Claude, working carefully at first: she would build with the AI in a chat window on her own computer, then copy and paste the results over to the Mac mini by hand, because she did not want to link any of her personal information to the new machine. She did not yet know that a tool called Claude Code existed, one built to run directly inside a program called a terminal instead of a chat window. For a couple of weeks, building anything meant a lot of copying and pasting back and forth, and a lot of asking the AI for step-by-step instructions, because all of it, from the tools to the terminology, was new to her.

Then she learned that Claude could run directly in the terminal, so the whole conversation could happen in one place instead of two. That discovery is what let the pace pick up.

Once it was clear the experiment was becoming something the whole practice would depend on, the team pulled in Max. Unlike Shaun and Ashley, Max does have a technical background, though not a conventional one. He studied philosophy and taught himself to code before Pillars hired him for a data-entry role, then quickly made the case that he could do far more than enter numbers into spreadsheets. Since then, he has added cloud infrastructure and AI-assisted development to his skills on the job. Max moved the platform onto Google Cloud for stronger security. Ashley had been building on Vercel, a website hosting service, and Supabase, a hosted database service. She had never heard of either one before she started using them; she was simply following where the AI’s instructions led. Max built, and still maintains, the database and cloud infrastructure the whole system runs on today and makes sure every new feature the team builds can connect to it safely.

The team still builds with Claude today. The AI features that staff interact with inside each hub run on a separate system called Vertex AI, chosen specifically for that job.

None of the three trained as software engineers. That is the point: the AI tool they used was capable enough that a psychologist experimenting alone on a Mac mini during her maternity leave could turn that experiment into the operating system a whole practice now runs on.

The three of them still work in a tight loop today. A team member raises a need (at first, it was mostly Shaun), often based on a specific frustration, like a supervisor unable to find a clinician’s current credentialing status without three phone calls. Ashley and Max talk it through with the AI, consult the team where needed, land on a plan, and build it. Staff who will use the new feature try it and flag anything that does not work through a bug-reporting feature built directly into the platform, a simple form where anyone can report an issue or request something new. Ashley works through that queue the same way she builds everything else, one item at a time, and a fix often ships the same day the issue is raised. New feature requests can often be live within days, sometimes hours.

Pillars sees this loop as its real advantage, and it has a name in innovation research. MIT’s Eric von Hippel has spent decades documenting “lead users”: people who know a problem so well that they solve it ahead of the market, often better than vendors do, because nothing is lost translating needs into specifications. Software has historically been built by engineers interviewing the people who will use it. At Pillars, the people who use it are the ones building it.

Phase 2: From First Launch to a Daily Rhythm

Ashley’s first hubs were marketing, CRM and credentialing, built on Vercel and Supabase. When Max moved the platform to Google Cloud, those hubs moved with it, and the first new hub built there was clinician availability, the roster intake uses to match clients. It replaced the spreadsheet-and-email approach described above with a single shared record. Once staff trusted it enough to stop double-checking it against the old spreadsheet, the team expanded hub by hub: continuing education tracking, chart auditing, Google Ads management and, eventually, more than 30 hubs.

Rather than saving up changes for one big release every few months, the team made small, reversible updates and shipped several per working day. Over the life of the platform, that added up to more than 750 individual database changes, called migrations, each one small enough that the team could check it, and undo it, without touching anything else in the system.

That habit of small checks is also what caught the system’s most persistent failure. Every hub is required to close out any task it creates, so nothing can sit open forever, but an internal audit found 14 tasks scattered across the system that nothing could ever mark finished, quietly piling up in staff queues. The team wrote an automated test that blocks any update creating a task with no way to close it. Nine days later it stopped a new feature that would have done exactly that, before it reached a live user, and it has blocked the same mistake at least eight more times since.

One Database Instead of Many Separate Apps

Every hub reads from and writes to the same database Max built when the team moved the platform onto Google Cloud. That single choice is what turned 32 separate tools into one operating system, instead of 32 disconnected apps that happen to share a login screen. It is also a large part of why Pillars can grow without growing its back office at the same rate.

Here is what that looks like in practice. When a clinician with open availability asks for marketing help, the operations team sees their current “accepting new clients” status straight from the availability hub, without anyone retyping anything. And a clinician’s approved insurance panels in the credentialing hub feed the new waitlist’s matching, so clients are not offered clinicians who are out of network. And because licensing status, credentialing progress, continuing education hours and training completions all live on the same profile, a supervisor can see exactly how close a supervisee is to independent practice by opening one page, instead of assembling it from three or four sources the way they used to.

Where AI Helps Today, and Where It Deliberately Does Not

Inside those 32 hubs, more than 40 individual features now use AI, and every one of them stops short of making a final decision. Here are the ones that matter most.

Assistants That Only Know Their Own Records

Seven built-in assistants answer questions only from the records they are given. The policy assistant answers only from published policies, names the policy it drew from, and says so when no policy covers the question.

Turning Paperwork Into Data

Statements, receipts, audit forms and meeting notes get converted into structured records automatically instead of being retyped by hand, and once that record exists, it feeds directly into whatever hub owns that information. An audit document, for example, becomes a line in the chart-audit register the moment it is processed, searchable and reportable like anything else in the system rather than a file sitting in a folder. This is the least exciting use of AI in the platform and probably the one that saves the most staff time.

First Drafts, Not Final Answers

Program descriptions, monthly reports and course proposals get an AI-written starting point that a person always edits before it goes anywhere.

Suggestions with Hard Limits Reached

In advertising, AI can suggest a budget or bid change, but the system caps how large any single change can be and refuses to touch a campaign that does not yet have enough performance data behind it. A person still applies the change. Chart-audit scoring works the same way: AI proposes a score against a rubric, and a reviewer sets the final number.

Working with Client Records

Two features do work with client records: chart-audit scoring, which reads a clinical note to check its documentation against a rubric, and insurance preauthorization letters, which draft a request from the diagnoses already in the chart. Both run inside the practice’s HIPAA-covered Google Cloud environment, and a person reviews every result. Neither one makes or recommends a decision about a client’s care. That line stays with the clinician.

What the team has deliberately not built is just as telling. There is no AI that talks directly with clients, and nothing that offers anything resembling a diagnosis, even though the team has both the technical skill and the clinical expertise to attempt it. That is not a gap in ability. It is the same AI proves, people attest boundary applied to the product roadmap: a choice to wait for clearer regulatory guidance, and better evidence about what actually helps people, in a field this sensitive, rather than move fast somewhere a mistake would be hard to walk back. When those are clear, the team expects to move as quickly as it did here.

People attest only works if the people are thinking. Assessment psychologists work inside this tension every day, so Pillars designed for it:

• AI shows its work: Chart-audit scores come with a rationale tied to specific rubric criteria, so a reviewer is checking reasoning, not accepting a number.
• Unverified stays visibly unverified: Every continuing education requirement carries its source and an unverified flag until a person confirms it.
• Limits are enforced, not suggested: Caps and data thresholds are written into the code rather than left to the reviewer’s discretion.
• Disagreement is measured: In the first 20 AI-assisted chart audits, reviewers changed at least one AI-proposed score in 18 (90%), and adjusted 15% of all item scores, most often scoring stricter than the AI. The compliance team re-reviews those changed scores, so overrides are checked too, not just counted.

Catching Bad Data Before It Causes Harm

Regulated numbers, like continuing education hour requirements or licensing thresholds, are the quiet risk in any compliance system: a wrong figure that looks exactly like a right one. The team built a specific, three-part protocol to catch that. Every continuing education requirement in the system is stored along with the source it came from. Anything that has not been checked against that original source is marked unverified, visibly, everywhere it appears, until someone confirms it. And where a figure should be calculable from the practice’s own underlying records, the system calculates it and flags any claim the evidence does not support.

That protocol has already caught a real example. Continuing education requirements first taken from a vendor’s compliance summary were stored as unverified, and the team replaced them with figures from the licensing boards before any of them went live. Checking those against the official state administrative code then caught a second error, an ethics requirement borrowed from the wrong licensing board, which was corrected within about a day.

Protecting Client Information

The platform runs entirely on Google Cloud, inside the practice’s own private cloud project, using Cloud Run, Cloud SQL and Vertex AI for the features that involve AI. All protected health information stays inside that environment. The practice has a business associate agreement with Google Cloud, the specific legal contract that allows a vendor to handle protected health information under HIPAA. That agreement is what covers any feature that touches clinical documentation, like chart-audit scoring, so that work happens inside a covered environment instead of a general consumer AI tool.

Access to each hub is tied to the practice’s existing Google Workspace groups, so adding someone to a team automatically grants the right hub access, without a second permission system to maintain separately. On top of that, the team built in specific safeguards:

• Pages holding clinical information log who opened them, independent of whether AI was involved.
• Documents uploaded for AI scoring are read in memory and never saved; only the resulting score and rationale are stored.
• Chart audits reference the chart by record number instead of copying the note into the system.
• If the system cannot confirm someone’s access, it denies access by default rather than assuming it is fine.
• Only two AI features read clinical content: chart-audit scoring and insurance preauthorization letters. Both were approved one at a time, and a person reviews every result. AI for sorting the waitlist is built but switched off.

Outcomes

Pillars of Wellness now runs its entire operation on this system. Continuing education tracking happens here. Credentialing, chart auditing and advertising happen here too. All of it runs on a platform the practice built and controls, shaped around how Pillars of Wellness works instead of a vendor’s assumptions about how a practice should run.

The clearest win has been consistency. Questions that used to require checking with three or four people now have one answer, because there is one record everyone works from. That shift alone has turned questions that used to take the better part of an hour into ones that take minutes.

It has also let Pillars grow lean. One biller supports more than 100 clinicians, and tools the practice once would have had to buy, such as compliance monitoring, are now built in-house, in one case in about a day.

The pace has held up too. New features have kept shipping in small, checked pieces several times every working day rather than in occasional, risky batches, adding up to more than 750 database changes without a major outage. And the data-integrity catch described above is not a hypothetical. It is a real example of the system doing exactly the job it was built to do, catching a compliance error before it could affect anyone’s credentialing status.

The system has also attracted outside attention. Pillars of Wellness was recently among the winners of the Futran Solutions (a digital technology and IT services firm) and AWS AI pitch competition in Valparaiso, IN, where Ashley presented the platform. The award, engineering support from Futran, on AWS, is going toward the next layer of the system. For a three-person team that started with a Mac mini and no engineers, that is a strong signal the approach holds up outside the walls of one practice.

It is worth naming one honest trade-off plainly: the system depends heavily on three people who understand it deeply. That is a real concentration risk for an organization this size, and one the practice will need to plan around as it grows. The team’s answer is the same discipline that built it: every change is small, documented and tested, and the Futran engagement is aimed at a documented, reusable architecture that doesn’t live in anyone’s head.

Who It Serves

For clients, the system is invisible, which is the point: nobody has to make three phone calls to find out whether a therapist is taking new clients. For clinicians, it means less time on administration, a clear view of their own path to licensure, and a workplace where a good idea about how the work should run can be built in days. For employers and community partners, it means a provider that can show its work, with the same shared data able to report, in anonymized aggregate, whether people are getting in, getting seen and getting better.

What Else Pillars Has Built

The hubs in this case study are only part of the platform. A few examples from the same three-person team, the kind of work nearly any service organization runs on:

• Partner billing: Rate cards for each partner organization, session notes recorded against them, and invoices generated from those notes.
• Statement reconciliation: Card statements are scanned and matched against receipts, and any charge without a receipt is flagged.
• Offer letters: Built from the practice’s compensation charts, emailed to the candidate, and signed by drawing a signature.
• Client transfers with escalation timers: A request captures a required reason, alerts the supervisor, offers the client to suitable clinicians, and escalates automatically if nobody accepts.
• Built-in ticketing: Staff report a problem from any page, fixes often ship the same day, and the person who reported it confirms the fix.
• More than 14,000 automated tests: Every change has to pass them before it can ship.

Built for Others

The same approach has carried beyond the practice. The team has used it to build tools for other organizations, including an assessment and reporting platform for an affiliated psychological evaluation firm and performance tools for a collegiate athletics program. Each follows the same rule as the Pillars platform: the software organizes the evidence, and a qualified person makes the call.

What Comes Next

Pillars is now looking at what the platform could become:

• A decision-support layer: With Futran, Pillars is building a system that identifies the practice’s current bottleneck, such as where client demand is outrunning clinician capacity, and proposes options. It recommends; people decide.
• Tools for other practices and partners: Pillars is in conversations about offering some of its tools, such as credentialing and compliance monitoring, to other clinicians and practices, and about outcome reporting for employer partners.
• A platform others could run: Pillars is exploring whether the platform itself could become a product other organizations operate, and welcomes input from practices, health systems, employers and investors who have thought about that path.

Conclusion

A 100-clinician practice with no trained engineers now runs on a platform it built and controls, shaped to its own operations instead of a vendor’s. AI made that possible by dramatically lowering the cost of building custom software.

What holds the system together, though, is not the AI. It is the rule the team enforced in code once they scaled the platform, and the safeguards they built around it: check what can be checked and route anything that needs judgment to the person responsible for it. The automated test born from an internal audit is what keeps unresolvable tasks from quietly piling up in staff queues. The data-verification protocol built on that same principle is what caught the incorrect continuing education figure before it could affect anyone’s credentialing status. Those two moments, not the speed of the build, are the real evidence that the approach works.

The lesson for other organizations is not simply that AI can help you build software faster, though it clearly can. It is that the real work is deciding, in advance, exactly what you will never let AI decide for you. Questions that can be checked against evidence are good candidates for automation. Questions that require a person’s professional judgment, with their name and license attached, are not. Most of the value in a project like this comes from the first kind of question. Nearly all of the risk lives in the second, and Pillars of Wellness built its entire system around knowing the difference.

Key Takeaways

• Let one person’s experiment prove the idea before you scale it. Ashley spent weeks copying and pasting code by hand on a Mac mini before anyone else on the team got involved. By the time the practice pulled in Max, its Director of IT, the approach had already proven itself.
• Decide what AI can’t do before deciding what it can. Pillars wrote its boundary into the software itself: AI checks facts, people make professional judgments, and the system stops and explains itself whenever those two get close.
• You don’t need an engineer to build real software. Two people with no coding background and one with some experience, working conversationally with an AI coding assistant, built and still run the practice’s entire operating system.
• Put the tools in the hands of the people closest to the work. Pillars’ advantage isn’t its code; it’s that the people who use the system are the people who build it.
• Design against the rubber stamp. Human review only protects you if humans can and do disagree. Make the AI show its reasoning, and measure how often people override it.
• Ship small, reversible changes instead of big releases. Several small updates every working day, adding up to more than 750 database changes, kept every mistake cheap to catch and easy to undo, instead of bundling risk into occasional big releases.
• One shared source of truth beats several systems that almost agree. Running all 32 hubs on a single database is what let the practice behave like one organization instead of a set of departments trading files.

A note on process transparency: This case study was drafted with AI assistance from source materials and editorial feedback provided by Pillars of Wellness and TechPoint reviewers, then reviewed and edited by a human author.