Screens, players and the software that runs them.

Common problems

Each one filters the catalogue to the work we have done on it.

• Screens on many sites, no single place to run them
• No way to tell what the screens are playing
• The data cannot leave our perimeter
• People get lost in the building
• Selling the advertising inventory we own
• Someone has to answer for what goes on screen
• A tender with a short deadline
• Something on site is broken and nobody knows why
• Too much of the week goes on documents and reports
• It has to talk to the systems we already run

In production

Live systems, with the scale each one runs at.

Six commitments

Each one links to the systems on this site that show it.

On-premises and air-gapped deployments

We do these routinely and do not price them as an exception. Data that has to stay inside your perimeter stays there.

Support comes from the build team

You get direct numbers for the engineers who wrote your system. They answer the calls themselves.

Ten of these systems are our own tooling

Proposals, diagnostics, documents and deployments run automatically here. Paperwork does not add to the price.

Current stacks, kept patched

We choose for a ten-year service life and keep the dependencies current.

Everything is documented

Runbooks, architecture and the reasons behind decisions. Another team can take the system over from the documentation.

Delivery measured in weeks

Setup is automated and the decisions are already written down, so a build that normally takes a quarter takes weeks.