Building Compliant MedTech Software in Australia: Real Requirements and Trade-Offs

If you’re building medical software in Australia, you’re not just writing code-you’re building a regulated product. The difference isn’t semantic. It changes architecture, hiring, timelines, and costs in ways that trip up founders every month.

Most Australian startups building in fintech or enterprise SaaS discover compliance as they scale. MedTech teams need to plan for it from week one. The regulatory bar is higher, the approval pathways are clearer but slower, and the cost of getting it wrong isn’t a fine-it’s criminal liability for directors.

Let’s talk about what actually matters.

The regulatory landscape: TGA, not the FDA

Your software probably needs TGA (Therapeutic Goods Administration) approval. The TGA is Australia’s medicines and medical devices regulator. If your product diagnoses, treats, prevents, or monitors a disease or condition, it’s a medical device. That’s the threshold.

The TGA has four classification levels (I through IV). Most software sits in Class II or III:

• Class II: Moderate risk. Think diagnostic support tools, patient management systems. Requires a Quality Management System (QMS) and evidence of safety/performance. Approval takes 6-12 weeks after submission.
• Class III: Higher risk. Life-critical decisions, treatment planning. Requires clinical evidence, full QMS, and notified body review. Approval can take 3-6 months.
• Class IV: Life-sustaining or life-supporting. Rare for software alone, but pacemaker software, insulin pump controllers sit here.

Class I devices are exempt from TGA approval but still must meet general requirements. Don’t assume your product is Class I just because it sounds simple-the TGA’s classification rules are strict.

The cost to bring a Class II device to TGA approval is typically AUD 80,000-200,000 in consulting, testing, and documentation. Class III is AUD 200,000+. That’s not the build cost-that’s on top of it. Plan for 6-9 months from decision to submit.

Quality Management Systems: Yes, you need one. No, it’s not optional.

A QMS is a documented system for how you design, build, test, release, and support your product. For medical software, this is not theoretical. The TGA will audit it. Your team will follow it. Your lawyers will reference it in court if something goes wrong.

You don’t need to reinvent it. ISO 13485 is the international standard for medical device QMS, and it’s widely adopted in Australia. Implementing it properly takes time-roughly 3-4 months for a lean startup, longer if you’ve already built without one.

A realistic QMS for early-stage MedTech includes:

1. Risk management: Identify what can go wrong and how you’ll prevent it (IEC 60601 family for software)
2. Design controls: Document how you went from concept to product, with traceability
3. Testing and validation: Prove your software does what it claims, under expected and edge-case conditions
4. Change management: Any code change is documented, approved, and tested before release
5. Post-market surveillance: Monitor real-world use, collect adverse events, investigate issues
6. Training and documentation: Your team knows the QMS and follows it

A lot of founders hear “QMS” and think bureaucracy. It’s partly that. It’s also risk reduction. Proper testing catches bugs. Risk management surfaces edge cases. Traceability means when a customer reports an issue, you know exactly which code version caused it and who approved it.

Data, privacy, and security: GDPR is a floor, not a ceiling

Medical software handles health information. In Australia, that’s governed by the Privacy Act and, if EU residents are involved, GDPR.

Standard security practice for SaaS-encrypted databases, HTTPS, role-based access-is table stakes. MedTech adds obligations:

• Data minimisation: Collect only what you need. If your app doesn’t require date of birth, don’t ask for it.
• Access controls: Multi-factor authentication, audit logs for who accessed what and when. If your customer is a clinic, their staff need granular permissions.
• Encryption at rest and in transit: Non-negotiable. Australian cloud providers (AWS Sydney, Azure Australia) meet this. Don’t use shared hosting.
• Incident response: If there’s a breach, you need a documented plan. Notify affected users within 30 days (Privacy Act) or 72 hours (GDPR).
• Data retention and deletion: Define how long you keep patient data and how you delete it securely.

Budget AUD 40,000-80,000 for a proper security audit and penetration test before going live. It’s worth it. A breach in MedTech isn’t just embarrassing-it’s a regulatory investigation, potential class action, and the end of your credibility.

Practical architecture: What actually changes in your code

Your architecture will look different. Here’s why:

Traceability: Every change to the codebase must be traceable to a requirement. Use semantic versioning and tag releases in Git with corresponding documentation. Your testing team needs to know which requirements each test covers.

Validation vs. testing: Testing is checking that your code works as written. Validation is checking that it solves the problem it’s supposed to solve. You need both. Build separate validation test suites that mirror real clinical workflows.

Audit logging: Every action a user takes-login, data access, decision support result, report generation-must be logged with timestamp, user ID, and action. This is table stakes for compliance and essential for post-market surveillance.

Configuration and customisation: If your software is used across multiple clinics, you need strong isolation. Patient data from Clinic A must not leak to Clinic B. Use separate databases or strict row-level security. This isn’t optional.

Deployment discipline: You can’t push updates whenever you want. You need change control procedures. Every release is tested in a staging environment identical to production. Rollbacks are documented. Hotfixes are only for safety-critical issues and still require documentation.

This doesn’t mean you can’t ship fast. It means your “MVP” process is tighter. You ship smaller features, more frequently tested, with better documentation. That’s actually better engineering.

Timelines and budgeting: What founders get wrong

A compliant MVP for Class II MedTech typically costs AUD 200,000-500,000 and takes 8-12 months, not the 28 days we quote for standard SaaS. That’s because you’re running two parallel processes: building the product and building the compliance evidence.

Founders often underestimate:

• Clinical input: You need actual clinicians (not just users) involved in design. Budget 20-30% of design time for iteration with medical professionals.
• Documentation: Non-trivial MedTech products have 100-200+ pages of QMS documentation. Someone writes and maintains this. Budget a technical writer or senior engineer part-time.
• Testing and validation: Expect 40-50% of engineering effort to go into testing. That’s higher than standard SaaS because the cost of bugs is higher.
• Regulatory consulting: You’ll hire a QMS consultant or regulatory affairs specialist. Budget AUD 100-150 per hour, 200-400 hours in year one.

If you have early funding and genuine clinical need, this is worth doing properly. If you’re pre-MVP validation, consider building a non-regulated decision support tool first-same underlying tech, lighter process-and graduating to full medical device status when you have customers and capital.

There’s a middle ground. A lot of founders skip full TGA approval because they sell their software as a “clinical decision support tool” that doesn’t diagnose or treat-it informs. That’s legally defensible but murky. Check with a healthcare lawyer before assuming you can avoid regulation.

Where to start

Before you commit to a 12-month compliance roadmap, do this:

1. Get a healthcare lawyer to classify your product under TGA rules. Ask specifically: is it a medical device?
2. If yes, talk to a regulatory consultant for a preliminary QMS assessment.
3. Map the cost and timeline realistically. If it’s outside your runway, decide: raise capital, pivot the product, or build non-regulated version first.
4. Hire your compliance person early. They should be in the room when architecture decisions are made, not brought in after code is written.

If you’re serious about MedTech and want to work with a team that understands both the engineering and the regulatory constraints, talk to Amora about your build. We build in regulated spaces. We know where the constraints actually matter and where founders over-engineer.

MedTech is slower than SaaS, but it’s not impossible. The startups that move fast are the ones that plan for compliance from day one, not the ones racing to launch and hoping lawyers fix it later.