How we work
The risky part gets proven first.
A seven-step path from concept to support, designed so that the interaction nobody has built before is tested while changing it is still cheap.
The method
Concept to support, with the risky part proven early.
Most experiential projects do not fail on the obvious things. They fail on the one interaction nobody had built before, discovered three weeks before the doors open. So that is the part we go after first.
- Concept
We read the experience, the audience and the production intent. Not the feature list: what is supposed to happen to a person standing in that room.
- Feasibility
We name the technical risk out loud, with its dependencies and the implementation path that removes it. If something cannot be built in that budget, in that time, in that venue, you hear it here and not later.
- Prototype
The uncertain interaction gets built small and tested, while changing it is still cheap. This is the step that decides whether the rest of the plan is real.
- Production
The full software, interaction and hardware layer, built to be operated by people who were not in the room when it was designed.
- Integration
AV, devices, sensors, services and third-party infrastructure, connected and tested together. The joins are where projects break.
- On-site
Deployment and testing in the real environment, and operation during the show. The venue always disagrees with the drawing.
- Support
Monitoring, maintenance and the changes that arrive after go-live, including the ones that arrive during the event itself.
Where a project usually starts
Three moments, three different jobs.
-
During the pitch
You need an honest answer on feasibility before you promise it to a client. We look at the concept and tell you what is buildable, what is risky and what would need to change. Nothing is charged into the project that is not agreed first.
-
Mid-production
The creative is approved and the technical path is not. We come in on the part that is unresolved, work to your direction and your timeline, and stay behind your name.
-
On something already running
A platform, an installation or a fleet that someone else built and that now needs to work, change or scale. We take on systems we did not write.
What this looks like in practice
The scope changes. That is not an exception, it is the job.
On a Mastercard hospitality project at the Venice Film Festival, the requirements changed after the presentation to the end client: graphical calendar, drag-and-drop rescheduling, database search, unregistered guests, multiple logins, messaging. The request arrived on a Friday afternoon and the first working version was online on the Monday, because the emails opening the bookings went out on the Tuesday.
That is only possible when the platform underneath already exists and the person changing it wrote it. It is the reason we build on our own stack rather than assembling someone else’s.
How far we go
To the joypad, if the joypad is the problem.
For an Enel X motorsport activation the gameplay was only half of it: the branded wireless controllers were designed and built for the installation, with their own firmware, and bridged into the game engine. For Mastercard, a fleet of connected devices runs in airports with a payment terminal and a QR reader inside, managed remotely from one platform.
Software suppliers usually stop at the edge of the screen. Most of the risk lives past that edge.
What we need to start
Less than you think.
The concept as it stands, even if it is a deck and a sketch. The date and the venue, if they exist. The constraint you are most worried about. That is enough for a feasibility conversation; the rest we ask as it becomes relevant.
The practical terms — NDA, white-label, procurement questions — are on the For Agencies page.
Planning something similar?
Talk to us before the technical choices become fixed constraints.