Written by Dr. Richard Soltero, President, InstantGMP, Inc.

The Question Nobody Asks When Evaluating GMP Software

When a regulated manufacturer evaluates GMP software, the checklist is predictable. Does it support electronic batch records? Does it handle 21 CFR Part 11 electronic signatures? Is it validated? These are the right questions. But there is one question almost no one thinks to ask, and it turns out to be one of the most revealing questions you can put to a software vendor:

What quality management system governs how your software is designed, built, and maintained?

After three decades in pharmaceutical operations and more than twenty years building regulated industry software at InstantGMP, I have come to believe this question separates vendors who understand compliance from vendors who sell into it. The answer reveals whether the people behind the software think like manufacturers, or whether they think like generic technology companies that happen to serve manufacturers.

What Most GMP Software Vendors Cannot Tell You

The majority of quality management software vendors are not themselves certified to any quality standard. Their internal development and operations processes are entirely informal. They may have a QA team, but that team is focused on bug testing, not on the broader quality management architecture that FDA regulations require from the manufacturers using their software.

This creates a fundamental paradox. A manufacturer is expected to operate under a rigorously documented quality management system, aligned to

21 CFR Part 211 for pharmaceuticals or

21 CFR Part 111 for dietary supplements. Yet the software they depend upon to manage and document that quality system may have been built inside an organization that has never been held to the same standard.

That gap matters more than most evaluators realize.

How InstantGMP Operates Differently

At InstantGMP, we made a decision early on that we would not just build software for compliance. We would operate as a compliant organization ourselves. Our quality management system is formally structured according to ISO 9001:2015, the internationally recognized standard for quality management systems. This is not a marketing claim. It is documented in our Quality Manual, which governs how we plan, design, develop, deploy, and continuously improve our software and services.

Our quality system is built on the Plan, Do, Check, Act (PDCA) cycle, the same framework that underpins sound quality management in regulated manufacturing. It covers every phase of how we operate:

• Leadership accountability and quality policy, established by the President and reviewed annually
• Risk-based thinking applied throughout our software development lifecycle
• A formal Software Development Lifecycle (SDLC) governed by documented policies, user requirements specifications, functional specifications, design documents, and requirements traceability matrices
• Computer system validation performed per GAMP 5 guidelines, with Installation Qualification, Operational Qualification, and Validation Summary Reports
• Internal audits conducted at planned intervals with documented findings and corrective actions
• Management reviews held quarterly, with documented minutes, metrics, and improvement plans
• A nonconformity and corrective action process (CAPA) that ensures defects and issues are tracked, resolved, and prevented from recurring

This is not overhead. This is the infrastructure that makes our software trustworthy over the long term.

What the SDLC Means for You as a Customer

When you choose a software vendor, you are not just choosing a product. You are choosing a development process. For regulated manufacturers, that distinction is critical.

Our SDLC documentation chain runs from the User Requirements Specification through the Functional Specification, the Detailed Design Specification, the Source Code Documentation, and all the way to the Requirements Traceability Matrix. Every requirement is traced from its origin through design, implementation, and testing. That traceability is the same discipline that your facility applies to batch manufacturing. We apply it to software manufacturing.

This structure is directly aligned with the expectations of FDA cGMP regulations and supports the computer system validation requirements your organization faces. When an FDA investigator asks about the software systems you use, your answer carries more weight when the system was built under a validated development process.

I have seen what happens when manufacturers rely on software built informally. Undocumented configuration changes that introduce compliance risk. Version updates that break validated workflows. Support teams that cannot locate the original design intent behind a feature. These are not hypothetical risks. They are the predictable consequences of software development without a quality system.

Risk-Based Thinking: Inside the Software and Behind It

One of the three foundational pillars of our quality management approach is risk-based thinking. We apply it at two levels that directly benefit our customers.

First, at the organizational level: our management team asks, at multiple stages in every process, what could go wrong and how we can improve. This prevents reactive problem-solving and drives us toward proactive quality improvement. The result is a software product that gets more reliable, more capable, and more aligned with regulatory expectations with each release.

Second, at the product level: our software itself is designed to support risk-based manufacturing practices. The electronic batch record system, the deviation and CAPA workflows, the document management system, and the inventory controls all embed the logic of risk-based thinking into daily manufacturing operations. Your team does not just use software that was built inside a compliant organization. They use software that actively teaches and reinforces compliant behaviors.

The Customer Satisfaction Metric That Tells the Real Story

Our quality objectives are measurable and monitored. One of our key metrics is customer satisfaction after major software releases. We track how many customer requests are incorporated into new requirements. We run formal surveys. We review these results at management meetings.

Why does this matter to you? Because it means we are not building features in a vacuum. Our development roadmap is driven by what regulated manufacturers actually need, validated against what they tell us. When your facility grows from clinical phase into commercial production, or when a new FDA guidance document shifts your compliance requirements, we are already working on the capability you will need.

That is not a sales pitch. It is the output of a documented customer requirements process.

Comparing the Long Game

I have watched manufacturers get burned by low-cost GMP software that looked functional at purchase and became a liability within three years. The vendor had no formal SDLC. Version updates introduced inconsistencies in the batch record format. There was no requirements traceability to explain why certain features behaved the way they did. When the regulatory inspection came, the manufacturer could not produce adequate documentation of the system.

Total cost of ownership in GMP software is not purchase price plus support fees. It is those costs plus the cost of revalidation when undisciplined development breaks your workflows, plus the cost of remediation when an inspection finds gaps in your system documentation, plus the opportunity cost of time your team spends managing software problems instead of manufacturing.

InstantGMP is designed specifically for the regulated manufacturer who is playing the long game. Our quality system is the infrastructure behind that design.

What This Means Going Forward

The regulatory environment for manufacturers is not getting simpler. FDA expectations around data integrity, electronic records, and computer system validation continue to intensify. The manufacturers who will navigate that environment most effectively are the ones who choose systems and partners that are built for it, not adapted to it after the fact.

Ask your next GMP software vendor to show you their quality manual. Ask them to describe their software development lifecycle documentation. Ask them whether they have ever been audited against an international quality standard. The answers will tell you more than any feature demonstration.

At InstantGMP, our answer is documented. And we are glad to share it.