ericwaller
Joined 19 years ago
Joined 19 years ago
But what’s really lacking is a model for multiple people sharing a single computing experience in real life. Companion mode in Google Meet or Spotify Jam are two attempts but both still force you through the one user, one device path.
Two adults sitting in a car shouldn’t have to constantly think “whose phone is this?” connected to CarPlay. Especially when they’re part of the same Apple “family” and on a Spotify family plan.
Two people seamlessly interacting with one “system” would break all sorts of auth and other assumptions, but it seems worth figuring out as computing becomes more and more prevalent in every facet of life.
The slightly longer answer is that we'll probably be the strongest option for smaller venues that want to do more complex stuff. To the extent that there's always some tradeoff between simplicity and power, we're likely to continue to lean pretty heavily on the power side for our core ticketing system.
It's amazing how many ticketing systems of various forms have been built over the years. It seems like one of those things that should be simple, but there are just so many ways to slice it.
While we're probably better known as a consumer app for buying tickets, SeatGeek also builds the full set of software you need to run a major venue. Everything from issuing and managing season tickets for the resident pro sports team, to working with promoters in selling tickets to their national tours and hosting the big, high-demand concert on-sales that accompany them.
A big component of our path into the market is that it's often the resident pro sports team that operates the venue and makes the ticketing decision. They tend to be very focused on the fan experience, particularly for season ticket holders, and that's our strong suit.
But latency (mostly) aside, there seem to be a lot interesting use cases for what is more or less programmable CDN configuration. Particularly when you have a relatively straightforward application (architecturally at least), but want to tap into the very distributed, very scalable CDN layer for little bits of critical functionality.
It was indeed Apple's "Sign In with Apple" deadline that prompted us to make the change (for those who don't know, apps that offer sign in via a third party auth mechanism will also need to offer sign in with Apple), but it's something we've considered on and off for many years.
Two big reasons. The first is that when we work with pro sports teams, fans of that team are able to sign in to their team accounts using SeatGeek. Having Facebook, and potentially Apple, also in the mix there felt like it would lead to a lot of confusion. The second is that while we've seen that sign in with Facebook leads to more sign ups in the first place, we've also seen that it causes confusion for users who are later unsure how they initially signed in, and that confusion can hit just as they're trying to pull up their tickets outside of an event.
http://ericwaller.com/
[ my public key: https://keybase.io/erwaller; my proof: https://keybase.io/erwaller/sigs/z8rRl3U4HJdLc-qnuPfEl4nHbgOThj13wRRDTkwQDaI ]