What shipped
A complete signage platform: design on a free-position canvas, publish a release, and run it across web, Roku, or Android players.
- Timeline
- August–September 2026
- Free-position editor
- Shared scene runtime
- Web · Roku · Android players
- Release publishing
- Device fleet
- Media pipeline
- Tenant API
- Billing
The problem
One canvas had to serve both the editor and every player.
The product needed a free-position visual editor, remote publishing, linked menu data, schedules, media, and screen management without letting preview and live playback drift apart.
The same system also had to survive venue Wi-Fi trouble, power loss, and different player hardware while keeping account and tenant data separated.
Product definition
The founding plan narrowed the first audience to restaurants, retail, venues, and offices, with a no-account demo and direct per-screen pricing as the entry point.
The product was split into four applications—web/admin plus web, Roku, and Android players—three Workers for the edge API, renditions, and scheduled jobs, and shared packages for scene schemas, rendering, editor behavior, widgets, player state, and API contracts.
One product, two offers
CanvasRelay carries the self-serve product. Studio Sussex Managed Displays uses the same platform for local businesses that want design, hardware, installation, and human support.
The editor is the proof
Visitors can open the real editor without an account, choose a template or blank canvas, place media and data freely, and see the same scene runtime used by the players. The live site exposes 46 starting templates without turning the canvas into a locked form.
Publishing creates a release rather than mutating a live board in place. Test sessions, release history, rollback, schedules, device health, offline playback, and multi-screen management make the editor part of an operating system rather than a design toy.
- Shared scene runtimebecause preview and player output need to agree before a screen can be trusted.
- No-account demobecause the product can prove its working surface before asking for registration.
- Release-based publishingbecause a venue needs history, rollback, and a known version on every screen.
A crawlable product surface
Static marketing pages cover features, players, industries, templates, pricing, and documentation. Explicit canonicals, segmented sitemaps, structured data, and app-shell noindex rules keep public pages separate from account state.
Edge platform, shared contracts
The monorepo contains four applications, three Workers, shared scene and editor packages, 36 tracked SQL migrations, and a typed client manifest covering 246 API operations. Bidirectional contract tests compare that client against the served OpenAPI document.
Cloudflare Workers split the edge API, media renditions, and scheduled jobs. D1 control and tenant databases, KV, R2, Queues, Durable Objects, Images, Workers AI, and AI Search bindings support tenant isolation, publishing, media, fleet state, exports, notifications, and billing.
Web, Roku, and Android players consume the same release model while preserving device-specific lifecycle, offline, and health behavior.
Real screens, not mockups.
What shipped
Shipped scope, test counts, and enforced budgets — not revenue. The product is live and self-serve; customer numbers stay private.
From venue build to standalone product
The editor, player, linked-data model, and fleet work grew from the Jungle Jim’s menu-board platform. Product hardening now supports both CanvasRelay accounts and Studio Sussex managed screens.
Have a problem that looks like this?
That's the kind of gap I close. Tell me what's breaking and I'll show you the system that fixes it.