A promise I could not keep
My website said, in two places, that Broadcasteer has no minimum spec.
I wrote that honestly. The idea behind it was real: the whole point of this software is that you should not need a rack of hardware and a five-figure budget to put your service or event on a screen. Run it on the laptop you already own. That is the product's actual thesis, and I still believe it.
But "no minimum spec" is not a thesis. It is a technical claim. And when I finally audited what the software genuinely asks of a machine, the claim did not survive contact with my own feature list.
This is the article about that audit.
Why nobody had done it
Here is the uncomfortable admission: in the project's entire history, I had never produced a hardware requirements document. Not once.
That sounds like negligence. It is more ordinary than that. Requirements documents get written when someone asks, and for a long time nobody did... because during development you run on the machine you have, and it works, so the question never surfaces. Features get added one at a time, each one cheap on its own, and the cost of the whole is never measured, because nobody ever runs everything at once except a real operator on a real live day.
That last sentence is the entire problem.
Features are cheap alone and expensive together
The core finding was not about any single feature. Every feature I measured was reasonable in isolation. The finding was about compounding.
Consider what a moderately ambitious live day asks for, all at the same moment:
- Several camera feeds arriving over the network, each needing to be decoded
- One of those feeds selected and composed into a program output
- Lyrics or slides rendered over the top of it
- The result encoded for streaming
- The same result encoded again, differently, for a local recording
- A separate output pushed to the network for other equipment in the building
- Audio captured, aligned to video, and mixed
- A confidence display running so the people on stage can see what is going out
Each of those, alone, is comfortable on a modest laptop. Run all of them simultaneously and you are asking one machine to decode several video streams, composite them, and encode the result multiple times over, continuously, for an hour, without dropping a frame... because a dropped frame in a live stream is not a glitch you can retry.
There is no honest way to describe that as "no minimum spec."
Scenarios instead of numbers
The temptation was to write a vague warning and move on. I wanted something an operator could actually use, so I built the document around scenarios instead of specifications.
A pure specification (some quantity of processor, some quantity of memory) is nearly useless to the person asking. They do not know how their planned setup maps onto it. So instead I budgeted four realistic live days, from the simplest to the most demanding, and worked out what each one genuinely costs. Then I named a small number of concrete machine profiles and matched them to those scenarios.
The result answers the question people actually ask. Not "what are the specs" but "will the laptop I have run the thing I am planning to do."
That reframing was the most valuable part of the exercise, and it applies well outside this software.
The network is hardware too
The audit turned up something I had been treating as folklore.
My shorthand for the network requirement was a particular class of consumer router... received wisdom I repeated because it had never failed anyone. I decided to test it rather than keep repeating it.
The shorthand turned out to be roughly right and precisely wrong. Right, in that the class of equipment is about correct for the load. Wrong, in that the number everyone quotes describes a headline speed, which is not the property that matters here.
What matters for multiple cameras on a wireless network is not the peak rate. It is how gracefully the network handles many devices talking at once, continuously, in the same room, for an hour... and whether it delivers evenly or in bursts. Two routers with identical numbers on the box can behave completely differently under that load, and the cheaper one is sometimes better because it is doing less clever scheduling.
I rewrote the guidance to describe the behaviour needed rather than the number on the box. Anyone can read a number off a box. Knowing which number is irrelevant is the useful part.
What changed on the website
The "no minimum spec" line came out. It was not true, and a claim that fails on someone's live day is worse than no claim at all... because they made a plan around it.
What replaced it is less catchy and more useful: an honest envelope, with scenarios, so a reader can locate themselves. Some readers will discover their existing laptop is fine, which was always the thesis. Others will discover that their planned setup is ambitious for their machine... and they will discover it in advance, at a desk, rather than fifteen minutes before their event starts.
The broader lesson
Two things came out of this that I would offer to anyone building anything.
First: the claims on your marketing pages are technical assertions, and they decay. Mine was true enough when it was written and became false as features accumulated. Nobody changed it, because nobody's job was to re-audit it. Marketing copy needs the same review cadence as code and almost never gets it.
Second: measure the whole, not the parts. Every individual feature passed review. The system, running everything at once the way a real operator runs it, told a different story. If your testing exercises features individually, and most testing does, you are measuring a machine nobody actually uses.
I would rather tell you what this takes than have you find out on your live day.