A Portable, Real-Time Presentation System Built from Scratch

Client: Prudential

Team: 2 senior engineers, 1 UX/creative, 1 product

Stack: Native iPadOS (Swift), Ruby, Raspberry Pi (Linux), custom hardware

The problem

Network Uncertainty in the Field

Prudential’s sales team needed to run coordinated, multi-device presentations in environments where they controlled nothing about the network infrastructure. Conference rooms in corporate offices are unpredictable. Venue wifi — when it exists — comes with captive portals, bandwidth contention, and firewall restrictions. Cellular signal varies by building.

Bluetooth, the obvious candidate for local device coordination, fails in ways that are difficult to diagnose and impossible to fix on site: pairing instability, range degradation in certain room geometries, interference from other devices in the building. We had seen Bluetooth fail in previous projects — not catastrophically, but in the subtle, intermittent ways that erode confidence. A connection that drops once during a demo is a problem. A technology that might drop is worse, because the presenter can never fully trust it. For a system that needed to work every time, in any room, Bluetooth was not an acceptable foundation.

The requirement was a self-contained presentation system with zero external dependencies: no venue wifi, no cellular, no pairing. The sales team needed to walk into any conference room, establish a local network they controlled, and synchronize a set of iPads in real time — all within minutes of arriving.

The problem

Three Components, One Portable System

The system comprised custom hardware (a Raspberry Pi configured as a portable access point), a lightweight event server, and a native iPadOS application. All three were purpose-built and designed to operate as a single unit with no external connectivity requirements.

Raspberry Pi Access Point

The network layer was a Raspberry Pi — roughly the size of a deck of cards — configured to broadcast its own wifi network with a known SSID. The iPads auto-joined on power-up; no manual configuration required. We selected the Pi for its minimal footprint and the fact that, with appropriate hardware additions, it could function as a fully self-contained router.

This architecture eliminated an entire class of environmental failure modes. The system operated identically regardless of venue infrastructure — a Manhattan high-rise with aggressive corporate firewalls, a suburban office park with saturated wifi channels, a basement conference room with no cell signal. The sales team brought the network with them.

We sourced the components, built the prototypes, iterated on the hardware configuration, and delivered the production units.

Native iPadOS Application

The iPad app was built natively in Swift for iPad Pro and deployed via enterprise certificates for internal distribution.

The app operated in two modes. Presenter mode gave the person driving the pitch full control — slide navigation, animations, transitions — executed simultaneously across every iPad in the room. The presenter’s device was the source of truth; audience devices rendered in lockstep. Audience mode displayed content and responded to server-pushed events with no local controls that could disrupt the presentation.

Beyond slide control, we built several features that extended the iPad into an active presentation tool:

Event Server

On the Pi, we customized the Linux installation to run a lightweight server written in pure Ruby — no Rails, no framework overhead. The server maintained persistent, bidirectional connections with every iPad on the local network via websockets and handled real-time event fanout.

When a presenter advanced a slide, triggered an animation, or drew on the whiteboard interface, the server pushed that event to all connected clients simultaneously. Latency requirements were tight: any perceptible delay between the presenter’s device and the audience devices would disrupt coordination. On a local network with a known, small client set, this was straightforward — the server’s job was connection management and message broadcast, not computation.

Ruby was a pragmatic choice. The problem was event coordination, not throughput. The team had deep fluency with it, and on a timeline measured in weeks, that mattered.

Real-time drawing with Apple Pencil. We built a custom drawing interface for the Apple Pencil, which was new hardware at the time. Presenters could annotate directly on the screen — sketch a concept, highlight a data point, respond to a question visually — and those strokes appeared instantly on every iPad in the room. The drawing surface supported multiple colors and stroke weights, designed for the kind of freeform annotation that happens mid-pitch when a prospect asks a question that isn’t on the slides.

Multi-presenter handoff. Prudential’s pitch teams had multiple presenters, each owning a section. The app supported seamless transfer of presenter control without device swaps or interruption to the audience view.

Private backchannel. Presenters could send signals to each other — “slow down,” “I want to add something” — that appeared only on presenter devices, not audience iPads. This gave the team silent coordination without relying on eye contact or pre-arranged cues.

Network Uncertainty in the Field

We ran three-week cycles. Each opened with an in-person session with stakeholders to set focus; each closed with a working demo, hardware, and software, followed by collaborative planning for the next iteration.

The structure gave Prudential direct influence over the product without requiring them to manage the team. Stakeholders shaped priorities and reacted to working builds. They did not write tickets or attend standups. Our job was to disappear for three weeks and return with something they could hold, use, and critique.

A few specifics worth noting:

Working software in the first cycle

Not wireframes. Not a prototype. A functional build that proved out the riskiest parts of the system — local networking, real-time sync, multi-device coordination. We front-loaded technical risk deliberately. If the architecture wasn't going to hold, we needed to know in week three.

Every cycle shipped stable, tested software

and updated hardware when relevant. Features accumulated on a working foundation. At the close of each cycle, the system was usable, not a collection of branches waiting to integrate.

Field-ready in nine weeks

By the end of the third cycle, the Raspberry Pi units, the server, and the iPad app were stable enough to carry into a client meeting. Subsequent cycles added features and refinements on a proven base.

Four people

Two engineers working across the full stack — native iOS, the Ruby server, Raspberry Pi hardware, and Linux configuration. One UX/creative lead. One product lead who ran stakeholder sessions and kept scope honest. No project managers. No coordination overhead.

What This Demonstrates

The technical problem was unusual: a self-contained system spanning custom hardware, a real-time server, and a native mobile application, all operating on a local network with no external dependencies. This required engineers who could move between embedded Linux configuration, network protocol design, server-side event handling, and native iOS development — including integration with hardware (Apple Pencil) that had barely shipped.

The delivery model was equally important. Working software at every boundary. Technical risk retired early. A team small enough to make decisions without process overhead, experienced enough to ship production hardware and software on a cadence that kept stakeholders engaged.

The result was a presentation platform a Fortune 50 sales team could carry into any room, deploy in minutes, and use to run a synchronized, interactive pitch — with real-time annotation, multi-presenter coordination, and private team communication — on hardware we designed, built, and delivered.

“We needed a responsive, web-based sales tool on a very tight deadline. BiTE guided us through every step of our project and were completely committed to our success.”

Lee Ames

Senior Director Product Marketing

“Our app’s spending system was more complicated than anything a dating app had done before. BiTE was able to make sense of each possible scenario and use BDD to test for every possible outcome. The result was an app that worked beautifully and didn’t drive us crazy in the process.”

Robin Leigh

Director of Communications

“We asked BiTE to pick up another vendor’s project. They audited the code and made corrections and improvements fast. They integrated seamlessly with our team as well as worked directly with our most important clients.”