Business continuity concerns with iNTERFACEWARE Iguana

I have been watching the iNTERFACEWARE situation for the last few weeks, and it has reached the point where I wanted to comment publicly.

Iguana is not a little utility sitting on somebody's laptop. For many organizations, it is the thing moving admissions, orders, results, referrals, documents, and billing data while everyone else gets on with providing healthcare. When the vendor behind that engine suddenly changes direction, the practical question is not whether the story is entertaining. It is whether the interfaces will remain supportable.

What can actually be verified?

There are plenty of colorful claims circulating online. I am not going to repeat the ones I cannot verify, and I do not know the circumstances under which any individual employee left.

The public record is concerning enough on its own.

An archived copy of the iNTERFACEWARE company page from 8 June 2026 listed five people in its leadership team: a VP of Finance, a VP of Sales and Marketing, Eliot Muir as founder and CEO, a lead developer and an HR manager. The page celebrated the company's people and workplace culture.

The current company page is startlingly different. It says that the company is now “mostly Eliot”. Engineering, sales and customer support are all assigned to Eliot, while human resources is marked vacant. It also says directly that the employees are gone and describes the one-person organization as an experiment whose results are still coming in.

That is not a rumor about a restructuring. It is the vendor's own description of itself.

There has also been a significant licensing statement. Eliot Muir has said that the next Iguana 6 release will be free, but that its new terms will prohibit running it on AWS, Google Cloud, Microsoft Azure or Oracle Cloud. He also said users of that release would need to sign the new terms.

Separately, iNTERFACEWARE now describes an intention to make Iguana X free under the Mozilla Public License 2.0. That direction may become interesting, but the same page says that the queue needs rewriting, the existing licensing system is to be removed, external dependencies are to be reduced, and the security model needs to be rethought. Those are plans, not a production support guarantee.

Why this matters even if Iguana is still running perfectly

The awkward thing about interface engines is that a healthy dashboard can make everything feel safe.

Your ADT feed can process every message today while the organization is quietly accumulating a very different sort of risk. Who answers a difficult support case? Who reviews and ships a security fix? Who can explain the licensing position to your legal team? Who maintains the build and release infrastructure? What happens if the one available person is ill, overloaded, or simply working on something else?

This is the old “bus factor” discussion, except it is no longer theoretical.

Healthcare interfaces also have unusually long lives. A channel created for a pathology system can still be running years later, complete with one strange Z-segment, a certificate that expires on a Sunday and a receiver that only accepts its own creative interpretation of HL7. The engine vendor does not merely provide an executable. It provides continuity around all of that accumulated behavior.

The proposed cloud restriction is another concern. Whether or not you agree with the security argument behind it, deployment location is normally a decision made by the customer's security, infrastructure and governance teams. A licensing change that rules out the major cloud providers can collide with an organization's approved architecture overnight.

Do not panic, but do not sit still

I would not turn off a working Iguana instance because of a dramatic webpage. Rushed interface-engine migrations are a splendid way to replace one risk with six new ones.

I would, however, do the following now:

• Export every channel. Put the Git exports or project archives somewhere controlled by your organization, not only inside the running engine.
• Collect the dependencies. Include Lua modules, VMD files, shared libraries, environment settings, certificates, connection details and a diagram of linked channels.
• Preserve safe test evidence. Keep de-identified examples of successful messages, failures, ACKs and edge cases. A channel without representative test data is only half an export.
• Get the commercial position in writing. Confirm the version you may run, where you may host it, what support remains available, and what happens at renewal.
• Test a restore. A backup that has never been restored is a comforting theory.
• Assess alternatives before there is an incident. The right time to prove a migration is while the existing system is still processing normally.

The engine is still only half the decision

Iguana became popular for good reasons. Its code-led approach is flexible, its live annotations are genuinely useful, and many teams have years of knowledge invested in it. None of that vanished in June.

But product capability is only one half of a platform decision. The other half is stewardship: support capacity, predictable licensing, security maintenance, release discipline and a migration path that does not depend on wishful thinking.

My conclusion is not “everyone must leave Iguana tomorrow”. It is that every Iguana customer now needs a documented continuity plan. Staying may be one option in that plan, but doing nothing is not a plan.

In the next post, I will look at the realistic alternatives, including the unglamorous option of staying put for a while, the emerging open-source choices, the large enterprise engines, and the newer systems trying to make this work less painful.