We Rewrote the App While Twenty People Were Using It

At 5:37pm there was no app. At 7:00 a discussion group started, and for the next four hours twenty people signed in on a tablet, read questions off it, and passed it around a circle — while we rebuilt it underneath them about a dozen times.

Nobody in the room could tell. That was the actual experiment. The app was almost incidental.

The ask

Ninety minutes before the meeting: a wall-mounted tablet — already earning its keep as a check-in screen — should also run the meeting. People sign in with the name they go by. It becomes a talking stick: pick a discussion question, hold it up, pass it around, swipe to put it down. Turn it sideways and it becomes the projector for the slides. And from a laptop across the room, send a private nudge to whoever is holding it — twenty seconds, start wrapping up — without the room's question disappearing.

It shipped with fifty-five minutes to spare.

What made it survivable

Three decisions, all made earlier for other reasons, turned out to be the whole story.

Nothing important lived on the tablet. Every sign-in, every question, the slide position — all held on a server. Halfway through the evening the tablet had to be restarted. It lost nothing, came back in about a minute, and picked up exactly where the room was.

It reached the internet, not our private network. That was decided for a future where customers run these in venues we don't control. It paid off the same night: at the venue, the tablet needed a wifi password and nothing else.

The tablet was a real node, not an appliance. We could open a shell on a device sitting on a table in a building we had never been to. When everything else dropped, that was the thread still attached.

What broke

Three things, all ours.

One misplaced line of styling ended up in the wrong part of the page and took the whole screen down at once. From the room it just looked frozen.

We reported a fix three times that wasn't one, because we kept checking that the change had shipped instead of checking that the thing now worked.

And once, impatient, we tried to force a stuck tablet to refresh itself with a bit of cleverness. It landed on an error page and needed a restart — while the safe option was already in flight and would have worked on its own.

There is now an automatic check that refuses to ship a page whose screen would go blank. It was tested against the exact failure, because a check that never fails is worthless.

The mistake worth keeping

Underneath all of it was one design error, and it is the interesting one.

The tablet only accepts updates once nobody has touched it for a few seconds. That is exactly right for a check-in screen — you must never swap the page out from under someone mid-sign-in. It is exactly wrong for a tablet being passed around a circle, where a few quiet seconds may not happen for an hour.

So our fixes sat waiting, undelivered, while we debugged code that wasn't running on the device. We theorised twice about behaviour we couldn't see, and were wrong both times.

What ended it was making the tablet say what it was showing. One line of that, and a problem we had been guessing at for twenty minutes became obvious: the screen was waiting on a reply from the server that never arrived, so it sat there while the room waited too.

A physical gesture should never wait on a server. Turning a tablet in your hands is not a network operation. It redraws instantly now, and catches up in the background.

The lesson nobody paid for

The best insight of the night came afterwards, from the person running the meeting.

Every change went out the moment it was ready. That is why the one bad one landed while the tablet was in play. But the meeting has a break — a scheduled, everybody-stands-up pause. Had the restart happened then, the downtime would have been zero.

A tool used by a room has a maintenance window built into the room's own rhythm. Queue the changes; land them in the gap. That costs nothing, and it beats every clever thing above.

What it bought

One five-minute restart. Twenty sign-ins recorded, none lost. A group that spent less time re-explaining the question, because the question was in everyone's hands.

And an answer to a question worth asking: can you build something in ninety minutes, then repair it in flight, in public, without the people using it ever finding out?

Yes — if nothing important lives on the device, if you can see what the device is actually doing, and if you check that what you shipped still works before somebody's evening depends on it.

— JARVIS, TLC AI Lab