Before You Build an AI Product in Allied Health, Read This

I've always been a tech guy. Straight out of high school I went into Software Engineering / Computer Science at Melbourne Uni because it seemed like the obvious path. But I was 18, more interested in playing footy and drinking beers with my mates than sitting in a computer lab. I remember staring out the window of a coding lab one afternoon on a beautiful day and thinking: I want a job where I can wear runners to work. I loved sport, so becoming a Physio seemed like a no-brainer. I ended up pivoting to aged care and disability rather than sport — but that's another story.

I've had a great career in Allied Health and I have no regrets (and I’m only just getting started!). I love the impact I've had. But in hindsight, I kind of wish I'd stuck at coding to be honest! I've never lost the tech side though. Before COVID hit, I built out the entire digital infrastructure for my previous Allied Health company: Microsoft 365, low-code automations, integrated workflows — back when most businesses in this sector were still running on paper and spreadsheets. These days I live in Notion, Airtable, Zapier, Claude and ChatGPT. I'm a builder, even if I'm not writing code.

Today I'm a strategic consultant who works with Allied Health and NDIS providers every day. I see what tools they're actually using, what they're paying for, what's gathering dust and what's causing more problems than it solves. I also work with clinicians and founders who are building tech products in this space, helping them pressure-test ideas, define their MVP, navigate regulatory complexity and get to market.

This post is for anyone in Allied Health thinking about building a tech product, particularly anything AI-powered. I want more people in this sector building things. I also want fewer of them burning $50k on something that Heidi will ship as a free feature next quarter.

Are you actually solving a problem?

This is where most ideas die, and it's where they should die if they're going to.

Development is faster than it's ever been. With AI tools, vibe-coding and low-code platforms — you can have a working prototype in days. The bottleneck has shifted. Building is the easy part now. Knowing what to build is the hard part.

I went to MedHack (a healthcare hackathon) a few weeks ago, and it genuinely shifted my thinking. Teams of smart, technically capable people spent the majority of their time just trying to figure out whether a problem was worth solving. Not building. Not coding. Figuring out if anyone actually cared enough about the problem to pay for a solution.

I see too many Allied Health products that skip this step entirely. Someone has an idea, they feed it to ChatGPT, ChatGPT tells them it's brilliant (because that's what ChatGPT does), and suddenly they're three months into development.

Here's the uncomfortable filter: is this a problem people will pay to fix?

A problem that annoys you is not the same as a problem someone will open their wallet for. It's hard to get money out of people for a new, unproven product from a solo founder with no track record in software. Heidi and splose have paying customers because they've spent years building trust, distribution and product-market fit. That's the bar. If you haven't validated willingness to pay before you start building, you're gambling.

Build the smallest possible version of your product and put it in front of real users before you build the full thing. Five honest conversations with potential customers will tell you more than six months of development.

"Reducing admin time" is the baseline, not the pitch

Pretty much every AI product in healthcare leads with "we reduce admin time." If your primary pitch is admin time reduction, you're saying the same thing as everyone else.

The honest truth: if you reduce a clinician's admin time by 30 minutes a day, most practices don't convert that into 30 minutes of additional billable work. They fill it with other inefficient activity, or the clinician takes a longer lunch. The productivity gain is theoretical until someone redesigns the workflow around it.

Your value proposition needs to go deeper than time savings. What clinical outcome improves? What revenue does it unlock? What risk does it eliminate?

Solve one problem, not ten

A pattern I see constantly: someone starts building software based on their own frustrations with existing tools, and the scope balloons into an attempt to replace five products simultaneously. They want to handle scheduling, compliance, communication, reporting and analytics all in one system.

Each of those is a company with a dedicated team solving one problem well. Xero does payroll. Employment Hero does HR. Teams does chat. Trying to replace all of them at once means you're competing on five fronts with a fraction of the resources. The result is usually a product that does ten things poorly rather than one thing well.

Pick the single problem where you have the deepest insight and the clearest gap in the market. Build for that. Nothing else. Not yet.

I've worked with multiple clinicians who have built genuinely impressive prototypes on their own. The technology is often good. The problem is almost always focus. When I get involved, the first step is stripping the product back: identifying the one workflow or sub-sector where there's a clear gap, defining the minimum feature set needed for a first demo and building a plan to get it in front of real providers fast. Narrow the focus, validate fast and let real user feedback tell you what to build next.

Know your competitive landscape

At the very least, run a deep research report through ChatGPT or Claude before you commit to anything. This is the minimum viable market research. I see people trying to launch products when someone bigger is already doing it better, and they haven't even looked.

There are three competitive threats worth pressure-testing against:

Platform risk

If your idea relies on practice management system data, or if it's something an established platform could realistically roll out as a feature, you need to think very carefully.

Look at what's already happening. Best Practice, Australia's most widely used GP software, integrated Lyrebird as a free AI scribe for all Bp Premier users. Free. Included in the platform. If you were building a standalone AI scribe for GPs, that market just evaporated overnight. It's a GP example rather than Allied Health, but the principle is the same: platforms with existing market share can bundle AI features at no extra cost because they're monetising the platform, not the feature.

In Allied Health, Heidi just partnered with BMJ Group to provide evidence-based clinical content directly within their platform, supporting over 2 million patient consults a week. Good luck competing with that if you're building an evidence or scribe wrappe. ShiftCare now offers AI-powered voice-to-text progress notes with automatic summaries, automated SCHADS Award interpretation and AI-driven workforce dashboards, all built into the platform. splose keeps shipping AI features into their PMS.

These platforms have the user base, the data access and the engineering resources to ship features faster than you can build a standalone product. If your product is essentially a feature request for an existing platform, that's a red flag. Why would someone pay for your bolt-on when the platform they're already using rolls out the same thing for free or at a fraction of the cost?

AI-native risk

If your product can be replicated (or near enough) by ChatGPT, Claude or similar tools — your moat is extremely thin. Why would a tech-savvy clinician pay for your specialised tool when they can get 80% of the value from a subscription they're already paying for?

ChatGPT has rolled out health-specific features. Claude keeps getting better at clinical reasoning. The general-purpose models are eating into what used to look like niche opportunities. Ask yourself honestly: what does my product do that these tools can't?

The vibecode test

If your product can be vibecoded in five minutes, the barrier to someone replicating it is effectively zero. That doesn't mean the idea is bad, but it means the idea alone isn't enough. You need something else: distribution, domain expertise, proprietary data, regulatory positioning, network effects. A technically simple product can still be valuable, but only if the moat is somewhere other than the code itself.

Your customers are not you

This is where I think a lot of Allied Health builders get it fundamentally wrong.

If you're reading this post, you're probably an innovator or early adopter on the technology adoption curve:

You use AI daily. You're comfortable with new tools. You see the potential immediately.

Your customers are not you.

A visualisation by Damian Player (shared by Steven Bartlett, among others) should give every health tech builder pause:

Each dot represents 3.2 million people. The full grid is 8.1 billion humans. Around 84% of them have never used AI. Not ChatGPT, not Claude, not even a voice assistant. Of the remaining 16% who have tried a free chatbot, only about 0.3% actually pay for AI tools. (The exact methodology behind these numbers is unclear, but the directional point is consistent with Pew Research data showing only 34% of American adults have ever used ChatGPT, and that's in the most tech-saturated market on earth.)

Think about where your target end user sits on the adoption curve. NDIS participants. Parents of children with disabilities. Aged care residents and their families. Support workers on rotating rosters. These populations are generally sitting much further right on that curve than the people building health tech products.

This creates a problem that many founders don't see coming: you're getting squeezed from both sides.

The small group of clinicians who are comfortable with AI (the early adopters in your potential customer base) will just use ChatGPT or Claude directly. They don't need your wrapper product. They're already paying for a subscription and they know how to prompt effectively. You can't out-resource the general-purpose models for this audience.

The vast majority of your potential end users (participants, parents, support workers, most clinicians) aren't using AI at all. Many of them actively don't want to. They've seen enough AI-generated slop to associate it with impersonal, low-effort service. For this audience, "powered by AI" is a turn-off. They want to talk to their clinician. They want a human who knows their child, their history, their context.

So you're building for a market that's split: one half doesn't need your product because they can already do it themselves with existing AI tools. The other half doesn't want your product because they don't trust AI with anything personal. That's a very narrow gap to thread.

I think it's a genuine mistake to assume that consumers (participants, parents, patients) want to interact directly with AI. If you're building a consumer-facing AI tool in Allied Health, you're building for a market that largely doesn't exist yet and may not want what you're offering when it does.

The clinician should still be the interface. AI should be invisible infrastructure that makes the clinician better, faster and more informed. In practice, that means tools that help a clinician prepare for a session, document it afterwards or spot patterns across a caseload. The value of the AI is experienced by the clinician, and the participant experiences better care without ever knowing AI was involved. That's a fundamentally different product architecture from "download our app and chat with our AI."

Friction kills everything

Every extra app, every extra login, every extra step in a workflow is friction. And friction kills adoption.

I say this as someone who is guilty of the exact same mistake. I'm a tech person and I have absolutely overloaded my own staff with systems in the past. Now, as a consultant, when I'm reviewing a client's tech stack I'm usually removing things. I see it constantly: practices running Zoom for telehealth when they're already paying for Microsoft 365, maintaining duplicate spreadsheets alongside their PMS because it can't track the things they actually need, layering Asana on top of Planner on top of email. Every extra system is cognitive load on clinicians who already feel overwhelmed.

So when someone pitches me their new product, my honest first thought is: why would I add this to my stack AND pay for it?

If you're asking a clinician or a parent to download another app, create another login and learn another interface (don’t get me started on client portals), you need an extraordinarily compelling reason. Most products don't have one.

Social proof is everything

Allied Health is a risk-averse sector. Clinicians and practice owners don't want to be the first person to try something. Before they'll even look at a demo, they want to know: who else is using this? What do they think? Can I talk to them?

If you don't have social proof, you don't have a product. You have a prototype.

This creates a chicken-and-egg problem that every new product has to solve. You need testimonials and case studies to get adoption, but you need adoption to get testimonials and case studies. The practical answer is to give early access to a handful of providers for free or at a steep discount, get their honest feedback, iterate based on what they tell you and then ask for a testimonial or a case study. Build your first five paying customers from your own network before you spend a dollar on marketing.

I see too many Allied Health founders skipping straight to marketing funnels, paid ads and landing pages before they have a single credible reference. Nobody in this sector is going to sign up for your product based on a Facebook ad. They're going to ask a colleague they trust whether it's any good.

Build traps

Outsourcing development

This one makes me nervous. Outsourcing dev work is a massive rabbit hole. Costs blow out. Timelines slip. You lose control of your own product. You become dependent on a team that doesn't understand your sector and has no incentive to keep costs down. I've seen this play out badly enough times to flag it as a standalone risk.

If you can't build it yourself (or with a technical co-founder who has skin in the game), be very clear-eyed about the cost, timeline and governance implications of outsourcing.

Regulatory and clinical governance complexity

This is the one most builders in Allied Health underestimate catastrophically. If your product touches clinical data, NDIS claiming, clinical decision-making or participant information, you're walking into a compliance landscape that includes the Privacy Act, the NDIS Quality and Safeguards Commission, clinical safety standards and potentially the TGA if your tool could be classified as a medical device.

Most early-stage builders don't budget for legal advice, privacy impact assessments or clinical governance frameworks. These are prerequisites, full stop. Getting this wrong doesn't just kill your product. It can create real harm for participants and real liability for you.

Data privacy is a bigger deal than you think

I'm constantly shocked at how blasé clinicians and Aussies are in general are when it comes to data privacy. Practices store sensitive health information in shared spreadsheets, the entire NDIS sector runs on filling out random referral forms loaded with sensitive participant data (I still can't get my head around that) and clinicians don't think twice about feeding client information into AI tools with unclear data retention policies.

If you're building a product that handles health data, you need to take this far more seriously than your users do. Because even if the clinicians buying your product don't ask hard questions about where data is stored, who can access it and how it's used — regulators will. And increasingly, participants and their families are starting to ask too. A parent who discovers their child's therapy notes were processed through an offshore AI model with no data sovereignty guarantees is not going to be understanding about it.

This is a genuine competitive risk as well as a compliance one. As awareness grows, products that can demonstrate clear data governance (Australian hosting, transparent data policies, clinical-grade security) will have a meaningful advantage over products that treated privacy as an afterthought.

The rabbit hole risk

I don't want to be the person who kills anyone's ambition. I want more Allied Health professionals building technology. But I also don't want people spending two years and $100k on something that could have been invalidated with a week of market research and five honest conversations with potential customers.

There's a reason I haven't built my own product. I'm an innovator when it comes to technology in this sector (or an early adopter at worst). I evaluate new tools constantly. I understand the technology well enough to do it. But every time I seriously evaluate an idea, I come back to the same conclusion: it's bloody hard and the moats are paper thin. The platforms are bigger than you, the general-purpose AI tools are better resourced than you and the market you're selling into doesn't have much money to spare. The bar for "something that's genuinely better than what already exists and that people will pay for" is higher than most people realise.

That's pattern recognition earned from working across dozens of Allied Health businesses, reviewing their tech stacks, watching what gets adopted and what gets abandoned.

So what should you build?

I'm not going to pretend I have the definitive answer, but I will say this: the gaps I see in the sector aren't where most people are looking. They're not in clinical documentation (Heidi owns that). They're not in general AI chatbots (ChatGPT owns that). The genuine gaps tend to sit in the messy, unglamorous operational spaces where regulatory complexity meets clinical workflow and nobody has built a purpose-specific tool yet. If that description resonates with something you've been thinking about, you're probably on the right track.

If you're serious about building something in this space, I'd genuinely encourage it. Just do the validation work first.

I help clinicians and founders pressure-test product ideas, define MVP scope, navigate the regulatory landscape and build a practical path to market. That ranges from a single session to stress-test an idea through to ongoing advisory as you take a product to market. For the right product and the right founder, I'm also open to deeper involvement. I know this sector inside out, I know what providers are actually struggling with and I know what they'll pay for. If you're building something that genuinely fills a gap, let's talk.