The demo checklist: questions IT and QA should ask a formulation-software vendor

A demo is easy to let wash over you — the vendor drives, everything looks smooth, and you leave impressed but not much wiser. To evaluate formulation software properly, IT and QA should each come with their own questions and insist on seeing answers on real work, not slides. Here's a practical checklist for both, so the demo tests the product rather than the pitch.

What QA should ask

QA's job is to probe the regulated core. Which markets' rules does it check, and how current are they? Show me it flagging an over-limit nutrient or an ineligible claim live. How does it calculate %NRV and elemental content — can I see it on our formula? Does it generate the label, COA, and spec sheet from the formula, and do they update when the formula changes? Is there version control and an audit trail — who changed what, when? Can it reproduce a past version exactly? The aim is to confirm the compliance and calculation depth is real, not a checkbox.

What IT should ask

IT's job is integration, security, and data. Is there an API, and what can it do? How does it integrate with our ERP? Where is data hosted, and is it encrypted in transit and at rest? How is access controlled — roles, permissions, single sign-on? How and where is data backed up, and what's the uptime track record? Can we export all our data, and what happens to it if we leave? These answers decide whether the tool fits your stack and your risk posture.

Make them demo it on your data

The single most revealing move is to bring one of your own formulas and ask the vendor to build it, check it, and generate its documents during the demo. Slideware hides gaps; your real product exposes them. A vendor confident enough to work on your formula live is showing you the product actually does what they claim.

Watch how questions are handled

Pay attention not just to the answers but to the manner. Direct, specific answers — including honest ‘not yet’ where something isn't supported — signal a trustworthy vendor. Vague reassurance, or deflecting the hard IT and QA questions to ‘we can discuss that later,’ is worth noting. The demo is a preview of the relationship.

Where Lemoniq fits

Lemoniq is built to be evaluated this way: bring a real formula and see the compliance checks, %NRV and elemental calculations, and generated label, COA, and spec sheet on your own product — while IT reviews the API, access controls, EU hosting, export, and integration. The demo is meant to answer the hard questions, not avoid them.

The takeaway

A good demo is an interrogation, not a presentation. QA should test the compliance and calculation depth on a real formula; IT should test integration, security, and data ownership. Insist on your own data, watch how the hard questions are handled, and you'll evaluate the product instead of the pitch.

Lemoniq welcomes the hard demo — bring your formula and your checklist. See how it works