A prototype is the drawing. We build the bridge.
Design and a Lovable prototype are the perfect input to this project. They are a risky thing to ship as the product, especially for a live event with no internet and no second chances. Here's how the two halves fit together, and why the build needs to be done properly.
How the two halves fit
This isn't design or build, it's design then build. Adam's visual design and the Lovable prototype define the look and the flow. Splitlight turns that into a production system that actually runs on the stand.
Design
- Visual design system
- Screen comps
- Lovable prototype as reference
Production engineering
- Offline-first architecture
- Data + GDPR layer
- Modular content model
What ships
- Offline touchscreen app
- Live admin dashboard
- Exportable, compliant data
Why the prototype isn't the product
Lovable is a genuinely good design and prototyping tool. The problem is only what happens when a prototype is mistaken for a shippable build.
Front-end deep, back-end shallow
AI prototypers generate a convincing surface over a thin, generic data layer. The hard part of this project, offline sync and compliant data handling, is exactly the part they do worst.
It spaghettifies as it iterates
Every change layers onto the last. The code gets less maintainable over time, not more, the opposite of what a modular, multi-vertical framework needs.
Online-only by default
Lovable + Supabase assume a live connection. This stand has no guaranteed internet. An online-only build simply doesn't run, this requirement alone rules out shipping the prototype.
It's a prototype, not a product
The gap between 'demos nicely' and 'runs reliably on hired hardware at a live show' is where these projects fail. A live event is the worst possible place to discover that gap.
In the last 18 months I've been brought onto three separate projectswhere a Lovable build couldn't be taken to production, founders stuck with a demo they couldn't deploy, Supabase integration gaps, and no clear path from prototype to live system. The fix each time was a proper rebuild. It's cheaper to build it right once.
What 'proper' means for this brief
Not gold-plating, the build scope maps one-to-one onto requirements that are already in the brief.
| Requirement | What the build does about it |
|---|---|
| No guaranteed internet at the stand | Offline-first: content bundled to the device, captures + events queued locally, auto-synced when a connection returns. |
| GDPR / PII, UK hosting, US client | 30-day retention, a client download window, automatic anonymisation after 30 days. Optional direct Marketo path to avoid storing data at all. |
| Modular, reusable across verticals + shows | Content-driven architecture, programs are data records, not hard-coded screens. New verticals and new shows plug in without a rebuild. |
| Live event, one shot, C-suite watching | Production-grade reliability: tested on the target hardware, idle-reset, graceful failure, no dependency on a network that might not be there. |
Who does what
Clean division of labour. Adam owns how it looks; Splitlight owns how it works. Design scope is reduced in the Splitlight quote accordingly, so there's no doubling-up.
- Visual design system (Fullsight identity)
- Screen-by-screen comps in 16:9 landscape
- Lovable prototype as the interactive reference
- Plane visualisation + standards-committee callouts
- Sign-off on the built UI against the design
- Production front-end (Next.js) from Adam's design
- Offline-first architecture + local-to-cloud sync
- Recommender logic + content data model
- Admin dashboard (analytics + leads)
- Data layer: retention, anonymisation, export, Marketo option
- Deployment to the Mini PC + handover to the stand builder
The architecture, in one picture
Four layers. The bottom three are exactly what a prototype skips, and exactly what makes this work on the day.
Built to be repurposed
The brief asks for a framework that expands to other verticals and to each org individually. That's an architecture decision, made up front. The build is layered so a new vertical, org, or show is a config change, not a rebuild.
- Content dataset (programs / courses as data records)
- Brand theme (logo, colours, fonts)
- Recommender matrix (roles × goals → recommendations)
- Enabled modules + copy (which screens and features are on)
- Affiliate / category selector
- Program / course detail (with optional plane visualisation)
- Recommender flow + direct browse
- Lead capture + QR / email outputs
- Admin dashboard
- Offline engine + local-first sync
- Data + GDPR layer (retention, anonymisation, export)
- Analytics pipeline
- Kiosk shell (idle, reset, hardening)
To repurpose it, you change the top layer only
Swap the content dataset and recommender matrix. Templates and core untouched.
Filter the dataset to one affiliate, swap the theme. Same build.
New content, new schedule, redeploy. No rebuild, no new licence.