raquo.net »

Startups have improved on many UX aspects of takeout payments for places like your local coffee shop. Some of these improvements have been customer-facing like contactless payments and automatic tip selection, others are more business-focused like simpler ordering interfaces and better user management.

Very few of these improvements have been implemented in for in-house restaurant payment. We’re still waiting for servers to return with a bill, handing off credit cards, negotiating bill-splitting, calculating tips and waiting again before you can leave. There are a few high-integration apps which solve these problems but I don’t think I need to explain the downsides of requiring some of your party to have to download and sign up for an app to gain these benefits. Takeout payment successes have been primarily focused on business hardware and plenty of takeout payment apps attempting to simplify the process from the consumer side only have failed, in no small part due to the app download hurdle.

Pay by Tray simplifies the payment process for consumers in sit-down restaurants without forcing them to opt-in to some app. Businesses get to simplify payment for customers, gain extra time that waitstaff usually spend running bills and gain additional options for customer payment. No app required.

The product is essentially IoT for bill trays. There’s a nicely designed (draws your eye but at the same time feels familiar) bill tray that has a screen and an NFC reader (maybe a EMV dip slot). At the very least, this prominently displays your bill total. At most, you can pay on the spot with a single phone or multiple phones, splitting the bill and selecting a tip amount without doing any math or asking the waitstaff to go out of their way to split things 5 ways. A small but obviously visible LED on the tray indicates the state of the transaction - pending, paying, paid, etc - so waitstaff can glance at the tray to see that users have paid, particularly because after payment they can just get up and leave.

---

I’ve been thinking about this idea for a little more than a year - my first notes on this are from October 2014 - but it recently came up again and I dug into the competition to see what was currently available. So far I’ve only found apps that users have to know about and download in advance, thus plenty of effort has gone into making these apps as much about supported restaurant discovery as they are about the actual payment. I think that’s probably a distraction.

It might seem weird to have another build log for a new project so immediately after the initial build log for Watercooler but they’re distinctly different project types to me. Watercooler is a thing I can build just by throwing some hours at the engineering, Pay by Tray is a project I’d do a lot of research on and then go find some funding for a pre-product development cycle. A v1 product is mostly backend and hardware engineering, neither of which I’m very good at so I can’t really jump into the engineering anyways. Well, I can and most likely will just to get things started eventually but this is not an idea I can launch on my own so searching for buy-in from others first is the smart move here.

This has only been on my radar again in the last 48 hours so I’ll dig some more and ask around for feedback from friends next. This is always the most exciting

I’m diving deeper into the idea discussed last week about a mix of pomodoro timer and breaktime video chat that I’m calling either Watercoolor or Workbreak. No code yet, I’m thinking about the simplest tech for implementation and how to attract the first 100 users.

Actually, my primary concern right now is whether or not I should build the thing in the first place. I’m keenly sensitive to where I decide to spend my time right now (possibly as a result of this blog and my efforts to try and keep my active projects list short) and I was really hoping to break away from a strictly software based project and do something more interesting. However, the more I think about the project, the more I think I can put a basic version together with a minimal amount of work. Plus I like the concept! I think I would enjoy taking 5 minute breaks to chat with other people about projects.

Frontend choices

Obviously my first instinct was to build on iOS. Easy to do local notifications when your timer is up, easy to get video from the camera, etc. Distribution is the problem here. Distributing to randos is entirely through the app store (enterprise distribution is still too hard because it’s designed for enterprise) which means a level of polish that I simply don’t want to provide for a version 1. App icons of multiple sizes, app descriptions, privacy policies, app review - all these things make it hard to publish a true beta. And I want to build a true beta.

My second thought was a Chrome extension. I don’t really care that it’s not 100% of the browser market, it’s enough of the market that I’ll be able to tell if people want to use it. Easy enough to make a browser action button that displays the timer, easy enough to send notifications when the timer is up, easy enough to open a window to start a new break video session. I don’t know what it takes to publish on the Chrome extension store, it doesn’t seem like much effort. Obvious drawbacks are not having a fucking clue how chrome background extensions work other than the simple example case I went through and javascript 🤔

Lastly, I could still leverage Swift and make a quickie Mac app. Again, the syntax is straightforward, I’m sure AVFoundation (camera) is similar to iOS and distribution can still be done ad-hoc and gatekekeper-approved, particularly now that Mac dev certs are a part of the yearly developer membership. But organizing and building a menubar Mac app (I am so sorry, I know you don’t need another) is unfamiliar. There are unknowns and it feels a bit more “heavy” that a chrome extension.

Backend

Regardless of frontend platform, I will need a WebRTC server running somewhere, possibly with other negotiation servers (I’ve looked only briefly into this). It seems like there’s plenty of open source solutions and a $5 Digital Ocean box should cover enough usage to start. There are a few free services which I may use - PeerJS looks good but I’m unsure of how up-to-date it is since some of the examples are broken. Presumably you’d have to use JS for the frontend for this one too. Even if I used a free (or paid) service I still need to keep track of which clients are “on break” and looking for a connection. Despite the upcoming shutdown of Parse, I may still use it for this purpose! We have a year, after all.