Developer and technology conference AV: when every session is a deliverable
A developer conference is not one show, it is a dozen running at once, and the recording of each one is a product the company ships afterwards. Multi-track capture, clean session recording at scale, livestream, and the on-demand archive. Here is what the AV scope has to carry.
By Studio AV team
A developer conference looks like a normal conference and scopes like a broadcast operation. The difference is that the content is the point. A company runs a developer or technology conference to ship knowledge: product announcements, technical deep-dives, workshops, and roadmap sessions that the attendees came for and the much larger absent audience will watch later. Every session is a deliverable, and the AV scope is built around capturing all of them cleanly, not just lighting the keynote.
Here is what that actually involves.
It is many shows at once, not one
A single-track conference has one room to get right. A developer conference has a keynote room and then several breakout tracks running in parallel, each with its own presenter, its own slides, its own demos, and its own recording. The production is really a set of simultaneous small productions coordinated by one team.
That changes the planning. Each track room needs its own capable setup: a vision capture, audio that records cleanly, slide capture, and a way to handle the inevitable live demo. The crew is sized for the room count, with a production manager coordinating across the rooms rather than one operator stretched thin. The most common failure on a multi-track conference is treating the breakout rooms as second-class, so the keynote looks great and the recordings of the technical sessions, which is what the audience actually wanted, are thin.
Every session has to be recorded to a usable standard
The recording is not a courtesy capture. For a developer conference it is the product the company publishes afterwards, and a thin recording wastes the speaker’s work and the company’s investment in the session.
A usable session recording means clean slide capture (the code on the slide has to be readable, which a camera pointed at a screen rarely delivers), clean presenter audio on its own track, a camera on the presenter, and the demo captured as a clean source rather than filmed off a monitor. Multiply that by every track and every session and you have a recording operation, not an afterthought. This is the same recording discipline that any serious capture needs, applied at conference scale.
The deliverable spec is agreed up front: the format, the naming convention, how quickly the sessions are needed, and whether they are edited or delivered as clean captures. Sorting that out after the event, from a pile of inconsistent recordings, is how conferences end up with an archive they never publish.
The livestream and the on-demand audience
Most technology conferences stream at least the keynote and often the main track, and the remote audience is usually larger than the room. The livestream is built broadcast-grade for the keynote, with the same redundancy any high-stakes stream needs: redundant encoders, a bonded uplink alongside the venue connection, and a stream director cutting for the home viewer rather than repurposing the in-room screens.
After the event, the recordings become the on-demand library. The value of a developer conference compounds for months as people find the sessions, so the capture quality matters long after the room has emptied. A clean archive is the difference between a conference that lives on and one that exists only as a memory for the few hundred who attended.
Demos, everywhere
Developer conferences are full of live demos, often several per session, frequently depending on a network and a device behaving live. Each one carries the same risk as a launch demo, and at conference scale the demos need a planned approach: a controlled network path rather than the public wifi, clean capture of the demo source, and a sensible fallback position for the high-stakes ones. A conference where every other session has a demo that stutters on the venue wifi is a conference that undersold its own content.
Where this fits
Developer and technology conference AV is part of our technology and launch work, scoped as a multi-room capture operation with the recordings treated as the deliverable they are. The broader picture of how conference scope changes with size is in our note on conference AV by scale.
If you are planning a developer or technology conference and need every session captured to a standard you can actually publish, send us the brief and we will scope the rooms, the recording, and the stream as one coordinated operation.
More on Industry
- Industry
Accessible event AV: the access provisions that have to be planned, not bolted on
Accessibility at events is a legal obligation in Australia, not a courtesy, and the provisions that make an event genuinely accessible all need lead time. Auslan, live captioning, hearing augmentation, and audio description, and why the AV team has to be in the access conversation from the start.
- Industry
Association and member conference AV: producing for an audience that owns the organisation
A member association conference answers to the members who fund it, which shapes everything: the budget is theirs, the AGM is part of the program, and the distributed membership means hybrid is the norm. Here is how the AV scope serves a member-owned event.
- Industry
Government event AV: neutral, accessible, and defensible by design
Government events answer to the public, which changes the production brief. The tone is neutral rather than promotional, access is a legal baseline, the recording is part of the public record, and the budget is accountable. Here is how the AV scope follows those expectations.