What If the Bill Could Just Split Itself? Inside a Live Multi-Device Prototype Built Entirely in ProtoPie
Inside a Real-Time, No-Code Prototype That Runs Across Five Devices Simultaneously
What if the bill could just split itself?
Five people at a table. One scan. The total divides, updates in real time, and clears the moment the last person pays. No calculator, no awkward Venmo math, no "I'll get you next time."
That's the scenario PaySplit demonstrates. But the real story isn't about splitting a bill, it's about what becomes testable when a prototype actually behaves like the product it represents.
The best product teams don't just design great experiences. They validate them before a single line of code is written. And that validation is only as good as the fidelity of what's being tested.
The Gap That Kills Good Products in Production
Research across fintech and consumer app design teams reveals a consistent pattern: the interactions most likely to fail in production are the ones the design team never properly tested. Not because they didn't know how to test them but because their tools couldn't simulate them.
Multi-device coordination. Dynamic data that recalculates in real time. Users joining a flow mid-session. These are standard scenarios in payment, delivery, and financial apps. They're also scenarios that most prototyping workflows force designers to fake, skip, or explain away during research sessions.
The result is predictable: incomplete test coverage, stakeholders approving flows that haven't been stress-tested, and edge cases that surface after launch rather than before it.
When a prototype can't reflect how users actually behave, you're not de-risking the product. You're deferring the problem.
What Genuine Fidelity Looks Like in Practice
To make this concrete: ProtoPie's Creative Technologist Nina built PaySplit, a real-time, multi-device bill splitting experience running across an iPad and four smartphones simultaneously.
No code. No backend. No shortcuts.
The iPad acts as the point of sale. Each person scans a QR code with their phone to join the session. The bill splits dynamically as participants join, recalculates automatically for uneven amounts, and updates across every device the moment someone pays.
It's not a simulation of a payment experience. It behaves like one.
That distinction matters for testing. When users interact with something that responds like the real product, what you observe reflects how they'll actually behave. The research is valid. The edge cases surface. The stakeholder presentation is grounded in something real.
The ProtoPie Capabilities That Make This Possible
PaySplit isn't a special build. It's a demonstration of what ProtoPie makes accessible to any design team working on high-stakes, multi-layered products.
- Multi-device communication without code. ProtoPie Connect lets devices communicate in real time natively, no server, no external integrations. One device can act as the source of truth, broadcasting live state to every other connected screen simultaneously. For designers, this means multi-party experiences can be tested as they'll actually work before a single handoff to engineering.
- Logic and dynamic data, built into the design file. Variables, formulas, and conditional logic run inside ProtoPie — no faked frames, no scripted workarounds. The prototype responds to every state change automatically, which means what you observe in a test session reflects genuine user behavior, not a guided tour through a happy path.
- Hardware integration that makes the first interactions real. QR scanning, camera access – ProtoPie integrates with device hardware so users enter the experience the way they actually would. That realism matters: when the starting point feels authentic, everything that follows is worth observing.
- Edge case coverage built into the flow. Devices joining mid-session, uneven amounts, out-of-sequence interactions... These are handled by design, not explained away during testing. The scenarios most likely to cause problems in production are the ones you can finally test before it gets there.
This is the tooling that closes the gap between "it tested well" and "it shipped well."
Why This Matters for Your Business
High-fidelity prototyping at this level isn't a design team luxury. It's a business decision.
For consumer payment products, the stakes of untested interactions are high. A checkout flow that breaks under real conditions, a split that doesn't calculate correctly for an odd group size, an onboarding step that fails when a user joins late — these aren't hypotheticals. They're the scenarios that drive churn, generate support volume, and require expensive post-launch fixes.
The design teams that catch these issues in prototyping rather than production operate faster, ship with more confidence, and spend less time in reactive cycles. The prototype becomes the risk management layer, not just the approval tool.
Teams that prototype at this level don't just catch problems earlier. They move faster because they're not rebuilding confidence at every stakeholder review. When the prototype behaves like the product, alignment happens in the session not across three rounds of revisions after it.
For teams that want to go further, ProtoPie's built-in user testing feature lets you run moderated sessions directly from the prototype so the research happens inside the same ecosystem where the experience was built, with no context lost in translation.
And for teams working under tight timelines, ProtoPie AI can get you to a testable, high-fidelity prototype faster without cutting corners on realism.
The Pattern Applies Beyond Payments
The architecture demonstrated in PaySplit — real-time state sync, dynamic calculation, multi-device coordination — is relevant anywhere your product involves more than one screen, more than one user, or data that changes in response to action:
- Retail kiosk + customer smartphone
- Driver app + passenger app
- Financial dashboard with live market data
- Multi-user onboarding and verification flows
- Loyalty program display app
If the experience has to work in the real world, the prototype should too.
Prototype at the Level Your Product Requires
The question isn't whether high-fidelity prototyping is worth it. For products where user behavior, real-time data, and multi-device coordination determine success, it's the only way to know what you're shipping before you ship it.
We work directly with product design teams to scope and build prototypes that match the real demands of your product so what gets tested is what gets shipped.
.png?fm=webp)
