Why early-stage medical device teams outgrow Google Drive for document control

Every medical device startup we've ever talked to began the same way: a shared Google Drive folder, a couple of SOPs in Google Docs, maybe a spreadsheet to track revisions. It's the path of least resistance — free, familiar, instantly accessible, and the team you have today probably doesn't need anything more.

Then you hire your sixth engineer. Then your tenth. Then somebody on the floor finds a printed copy of an SOP that doesn't match the one in Drive, and nobody can tell whether the printed one is current. Then a notified-body auditor asks for your document control SOP, and you realize you don't have one. Then somebody opens a CAPA, and the corrective action is "fix the document control system" — which is now your problem to solve.

Google Drive doesn't fail you all at once. It fails you in small ways that compound: version confusion, slow approvals, gaps in training records, and an audit trail that doesn't exist. Here's exactly what breaks, and what a minimum viable document control system looks like when you replace it.

The five failure modes — in the order they show up

1. Version confusion

Drive's "version history" tracks the file. Your QMS needs to track the document — a specific code, at a specific version number, with a specific status (draft, in_review, approved, effective, retired). When somebody opens Manufacturing SOP - v2 FINAL.docx and somebody else opens Manufacturing SOP - v2 FINAL (1).docx, you have a quality problem, not a file-naming problem.

The fix is structural. A real document control system gives every document a permanent identifier (e.g. MFG-SOP-001), maintains the version history as a property of the record rather than the filename, and surfaces a single canonical "current effective version" to every user. Drive can't do any of those.

2. Approval bottlenecks

In Drive, "approval" is a comment thread or an emoji. There's no enforced workflow that requires the right people to sign off, in the right order, before a document can be considered effective. Worse: there's no record of who approved what, when, and with what meaning ("Reviewed," "Approved," "Approved with comments").

At 5 people you can fix this with discipline — everyone knows the rules, everyone follows them. At 15 people, somebody approves an SOP via a Slack thumbs-up and nobody can find it in the audit. ISO 13485 clause 4.2.4 doesn't suggest you control document approval; it requires it.

3. No real audit trail

This is the one that ends auditor sympathy. Drive shows you the last few revisions of a file. It does not show you who changed which field in which record, when, with what reason, in tamper-evident form. It does not log who approved an SOP, who rejected a CAPA stage, who read a revised work instruction. It cannot.

21 CFR Part 11 § 11.10(e) requires "computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records." Drive's revision history doesn't qualify — it's a file-level diff, not a record-level audit log. An auditor will not accept it.

4. Training and acknowledgment gaps

ISO 13485 clause 6.2 requires that personnel performing work affecting product quality be competent on the basis of "appropriate education, training, skills and experience." That means: when you revise an SOP, the people whose work it governs must be trained on the new revision and acknowledge they read it.

In Google Drive you can email people the link and ask them to reply "read." Some will, some won't, the replies get buried, and three months later you can't tell who's on the current revision and who's still operating off the old one. Real document control links training records to document revisions automatically — read the doc, sign the acknowledgment, the record is preserved.

5. The "works at 5, breaks at 15" wall

All four of the above are tractable when the whole quality team is two people who share a coffee maker. They are not tractable when you've grown to a dozen engineers, two production lines, three contract manufacturers, and a quality manager you just hired who's looking at your "system" with the polite face of someone trying to be diplomatic.

The numbers we hear most often:

• • 1–5 people: Drive is fine. The team has perfect shared mental state.
• • 6–10 people: Cracks appear. People print copies. Acknowledgments go uncollected.
• • 10–15 people: The first audit happens. The first CAPA against your QMS gets opened.
• • 15+ people: You are now operating without document control, and you know it.

The teams that handle the transition well make the move before they're forced to. The teams that don't, do it during audit prep at triple speed.

What a minimum viable QMS actually looks like

You don't need MasterControl. You don't need Veeva Vault. You don't need a $50K/year platform with a six-month implementation. Most startups at your stage need five things, period:

• • Versioned documents with a real lifecycle — draft → review → approve → effective. Sections, not whole-file uploads. A permanent code per document; the version is a property of the record.
• • 21 CFR Part 11 e-signatures — unique user, name + date/time + meaning, password re-authentication at the moment of signing. Not a Slack thumbs-up.
• • Tamper-evident audit trail across every record change. Per-field old-value / new-value capture, chained for cryptographic tamper detection.
• • Training records tied to document revisions. When a doc revises, the people whose work it governs are reassigned automatically and their previous acknowledgment is rolled forward as the historical record.
• • A starter pack of SOPs mapped to your standard (ISO 13485, ISO 9001, dental, food-safety). You shouldn't be starting from blank pages on day one.

If a platform you're evaluating gives you all five of those, with public pricing under a few hundred a month, and you can sign up and use it without a sales call, you have your answer. If it gives you those plus 200 features you don't need yet and a quote you have to request — that's a different problem.

When to make the move

The honest answer: before your first audit, and ideally before you cross 10 users.

The cost of migrating a 50-document Drive QMS into a proper system is real but bounded — a focused week for one person, less if your new platform ships with starter templates you can populate. The cost of not migrating shows up as an audit finding (a real one, with NCRs and CAPAs), or as a six-month delay to a clearance because your design history file can't be reconstructed, or as a six-figure consulting bill to get audit-ready in time.

The teams we see succeed do it on their own timeline. The teams that wait until the auditor's calendar makes the decision for them do it the hard way.

The honest case for staying on Drive

We try to be even-handed about this. There are situations where Drive is genuinely fine:

• • You're pre-revenue, pre-clinical, and pre-employee. Two cofounders writing exploratory protocols — fine.
• • You're a non-regulated business that doesn't ship a physical product. Different conversation.
• • You have a real plan to migrate before any of: hiring an external auditor, applying for ISO certification, submitting an FDA 510(k), or scaling past 10 employees.

If any of those three doesn't describe you, you're already past the point where Drive was the right tool.

What we built ArvoDocs to do

ArvoDocs is the minimum viable document control system for early-stage regulated teams, plus the audit trail, quality events, training, and supplier management you grow into. Starter plan is free forever (up to 100 documents, 10 GB storage). Compliance packs deploy 21–51 starter SOPs, work instructions, and event templates in one click. Self-serve signup — no demo, no sales call, no procurement cycle.

If the failure modes above sound like next quarter's problem, it's worth thirty minutes today to see if a better system would change that.

Frequently asked questions