IMAX Owns Every Layer Between the Camera and Your Retina. That Is the Whole Product

As of 31 March 2026, IMAX operated 1,865 systems across 91 countries. In 2025 it grossed $1.28 billion worldwide — up 40% on 2024 and 13% above its previous record year in 2019 — and it has spent 2026 signing laser rollouts across Australia and New Zealand, the southeastern United States, Vietnam and the suburbs of Paris.

Those numbers are interesting. The engineering underneath them is more interesting, and it makes an argument most software architects have been trained to reject.

The unfashionable position#

Modern platform engineering has a strong default: assemble best-of-breed components, connect them with standard interfaces, avoid lock-in, swap anything that underperforms. It is good advice most of the time. It is how we build most systems, and it is why “boring tools, loosely coupled” is our usual recommendation.

IMAX does the opposite, deliberately and completely.

They specify the capture format. They specify the film or digital master and do their own remastering pass on it. They build the projector — a custom optical engine with proprietary lenses. They specify the screen size, its curvature, and its coating. They specify the geometry of the room: seat rake, sightlines, distance from screen. They tune the audio system per venue. And then they certify the whole installation and keep certifying it, with their own technicians maintaining the equipment.

You cannot buy an IMAX projector and put it in your own room. The room is part of the product.

That is a stack with no seams and no substitutions, and it exists because of what IMAX is actually selling.

What they are selling is a guarantee#

Here is the distinction that matters, and it generalises far beyond cinema.

Most products sell a capability. A projector manufacturer sells a projector with a specification sheet. What you do with it, in what room, with what content, is your problem. If the result is disappointing, that is not a defect — the projector met its spec.

IMAX sells an outcome: you will have this experience, in any of 1,865 rooms, anywhere in 91 countries. That promise is the entire brand, and it is why people pay a premium for a ticket to the same film showing cheaper down the corridor.

You cannot guarantee an outcome across components you do not control. This is not a philosophy, it is arithmetic. Every interface between two independently-specified components is a place where tolerances stack, assumptions diverge, and someone’s “good enough” becomes someone else’s input. Ten components each meeting spec 98% of the time produce a system that meets spec 82% of the time. And critically, when it fails, no individual vendor is at fault — which means nobody fixes it.

The moment your promise is about the end-to-end result rather than a component’s behaviour, you have to own the chain or contractually control it. IMAX chose to own it.

Where this applies in software#

I raise this with clients who are deciding how much of their stack to assemble versus build, and the deciding question is always the same: what have you promised, and to whom?

If you have promised a capability, assemble. Your users are engineers, they understand the components, and they can compensate when something underperforms. Loose coupling, standard interfaces, replaceable parts. This is most internal platform work and it is the right default.

If you have promised an outcome, control the chain. And be honest about how far the chain extends.

We hit this constantly in vertical software. When we deploy a Hospital Management System, the promise is not “these modules meet their specifications.” It is that a clinician can complete a task reliably, that the data is correct at the point of care, and that the system is available when the ward is busy. That promise spans the database, the integration layer, the network in the building, the tablet hardware, and the login flow. If we assemble those from independently-chosen parts and hold none of them accountable to the end-to-end outcome, we have not delivered a system — we have delivered a collection, and the hospital gets to integrate it.

The same is true of a School ERP that promises attendance is accurate by 09:15 every morning. That promise reaches back through the register app, the network in the classroom block, the sync mechanism, and the identity mapping between four source systems. Any one of those can meet its own spec and still break the promise.

The cost, stated honestly#

Vertical integration is expensive and it has real failure modes. It is worth naming them rather than pretending the trade is free.

You are now responsible for everything. Every layer you own is a layer you maintain, staff, and upgrade. IMAX employs technicians to service installations because nobody else can. That is a permanent operating cost, not a one-off build cost.

You move at the speed of your slowest layer. When a genuinely better component appears, you cannot simply adopt it — it has to be integrated into a system tuned around the old one. The laser retrofit programme running through 2026 is exactly this: upgrading an installed base of nearly two thousand certified rooms is a multi-year capital programme, not a firmware update.

You can be wrong about the whole thing. A best-of-breed assembly can survive one bad choice. A vertically integrated system built on a wrong foundational assumption has to be rebuilt.

So the honest guidance is: integrate vertically only where the guarantee lives, and assemble everywhere else. IMAX does not manufacture its own seats or run its own cinemas. It controls the specific chain between the source image and the viewer’s eye, because that chain is the promise, and it partners for everything outside it.

That is the discipline worth copying. Not “own everything” — identify precisely which components determine the outcome you have promised, own those completely, and be relaxed about the rest.

The test#

Ask two questions about your system.

What have we promised, in the user’s language? Not “99.9% API availability.” Something a user would recognise as a promise: the results load on results morning, the record is correct when the clinician opens it, the report goes out on the first of the month.

Which components, if any one of them fails, break that promise? That set is your integration boundary. Everything in it needs a single owner, end-to-end testing, and accountability that does not fragment across vendors. Everything outside it can be assembled, swapped, and argued about at leisure.

Most teams have never drawn that boundary, which is why their incidents always live in the gaps and their post-mortems always conclude that every component was working correctly.

---

Every component met its spec and the user still had a bad experience — that is an integration boundary nobody drew. We draw it, then own it. Tell us what you have promised.