This post is the first in a series of articles that explains the entire process of designing, developing, and launching Wait Times by Magical Trip Guide, a theme park ride wait times appI released to the App Store in July of 2020.
In fall of 2018, my wife, Kelly, began a career transition into becoming a travel agent, specialized initially on theme park vacations (Disney and Universal). Given my expertise in all things tech, I became the de-facto IT director for our new two-person venture. Initially, this meant setting up a content website, social accounts, email newsletter, etc. As I’ve always been interested in the sales/marketing side of business, I was also excited to take the lead on marketing efforts (SEO, paid advertising and the like).
Why: tools as marketing
In spring of 2019, I stumbled upon an interesting marketing-focused blog by Neil Patel, a highly-respected thought leader in the SEO space. One of his ongoing themes is that offering utility to potential buyers, in the form of a handy tool, is one of the best ways to get inbound leads, improve SEO, and generally elevate your authority on a topic. He has written at length about how acquiring Uber Suggest, a keyword research tool, has been a massive boon to his business. The general idea is: drive lots of traffic to a tool that people find useful, and some subset of those people will ultimately convert into buyers.
This idea struck a chord with me, particularly because I was in search of new marketing channels for the travel business, and because I happen to really enjoy building software. I started brainstorming what sorts of tools would be useful to our audience and surveying the market for potential unmet needs. Thinking back on our own time at theme parks, I kept coming back to the idea of ride wait times.
The major theme parks all have their own apps that feature ride wait time estimates, but they also include a kitchen sinks worth of other content. To put it lightly, the apps are fairly bloated, not super easy to use, and just finding the wait times for a ride can be cumbersome. I’ve always been a huge believer in the product approach of finding a very specific problem and solving it in a way that makes your solution irresistible to potential buyers, the so-called “one thing” approach.
So with that, I had a solid idea to pursue, albeit an idea that needed to be validated against my overall goals for the project.
Goals
Once upon a time, I would naively start projects purely due to my own interest in technology, with little to no regard for what I aimed to achieve or how I might ultimately benefit from the time investment. A funny thing happens as you get older though, you start getting better at valuing your time and assigning a dollar amount to it, simply because you don’t have as much supply on-hand. Now days, I try to be very calculated about where and how I spend my time. A new project has to have a defined set of goals attached to it and a clear value proposition.
In this case, the primary goal was to drive inbound leads to Kelly’s travel business via the app. Secondary goals would include: making some cash to partially offset my time cost (bonus really) and learning a handful of new technologies (more on this in later posts).
These goals made it easier to determine a pricing scheme later on and to sketch out what success would look like. When your primary goal isn’t revenue, it changes what metrics you care about most, and it makes it easier to not stress about dollars coming in.
Features and functionality
The next step in the process was to figure out what the app’s feature-set might look like. Given that there are other apps out there that offer ride wait times, it wouldn’t make sense for me to bother making my own unless I could bring something novel to the table.
High-quality, platform-adherent user experience
As I mentioned above, the primary frustration I had with the existing apps was how difficult they were to navigate and use. They also didn’t really feel very native to iOS, straying away from the Apple design language in strange and sometimes jarring ways. My app would look and feel like an app that Apple itself might create, adhering to platform conventions, supporting dark mode, and providing a top-notch accessibility experience, among many other things.
Low wait time alerts
Another frustration with the other wait time apps was how they are all active experiences, by that I mean, you have to constantly check the app for updates on wait times. Imagine an e-mail or chat client that couldn’t send you push notifications upon the arrival of new messages; this would be a frustrating experience to say the least.
In that same regard, it would be great if the app could be configured with a wait time threshold for a given ride, and then notify you when the wait time drops to that level. Now the app isn’t just valuable when you’re actively checking it, but instead, it’s constantly working on your behalf silently behind the scenes, letting you know when a notable event occurs.
Leverage location services
The ability for your phone to know your current location continues to be one of the most powerful features of modern mobile devices. A large, sprawling theme park is naturally a great candidate for leveraging that information, especially where it relates to ride wait times. The biggest reason for this is that it takes a while to walk from one side of a park to another. If your goal is to maximize your park time, it would be great for the app to help you.
One way I could make use of location would be to include a feature that would mash up the list of rides with currently low wait times and the list of rides nearest your location. A “ride now” section that would give you instant access to rides you could walk to in a short time, and not have to wait very long to ride.
Another feature might make use of location and maps. Showing a pin for every single ride in a park and color-coding each based on wait time level would make it very easy to identify clusters of low wait time rides. Adding in the user’s current location would make it simple to make their way to said clusters.
Siri Shortcuts
In iOS 13, Apple amped up developer access to Siri with the introduction of Siri Shortcuts, a mechanism by which developers could expose their app data and interactions to Siri and the Shortcuts app. None of the apps I had seen in the space were utilizing this functionality, so it felt like another opportunity to do something unique and useful. Adding a Siri Shortcut for “check ride times” would allow users to simply ask Siri for the information via voice or to incorporate the data into any of their own shortcuts.
Table stakes
Aside from the marquee differentiating features, I defined a list of “table stakes” features that one would expect out of an app like this. This list included:
- Fullscreen rides list with name, status, distance from user, and current wait time.
- Platform-native search functionality with as-you-type filtering.
- Ability to create a favorites list of rides.
Feasibility
With goals and a feature list in hand, I needed to determine if this idea would even be technically feasible, and if so, what technology might I ultimately want to leverage.
Theme park data
The first, and probably most significant question was around how to obtain the ride wait times for each park. There are a number of third-party wait time apps on the App Store, so I suspected that it was unlikely for each to be crowd-sourcing data on their own. A bit of Googling quickly uncovered a promising candidate; an open source node-js library that queries the unofficial API’s for each major theme park. The library imposes strict limits on the frequency of queries, primarily to be kind to the theme park back-ends, lest they become irate enough to try and shut down access. This would be something to consider when designing the back-end architecture for the app, but importantly, the data was available.
Back-end infrastructure
It was pretty clear that even with the theme parks node module, I’d still need to build my own back-end service to power the mobile app. At a high level, the service would have to support the following functionality:
- User records for storing favorites and low wait time alert configuration.
- Ability to send push notifications.
- Update and store the latest park info / wait times and service that data to the app.
- Host any static assets I may need, such as images and other media.
While I had built my own server back-ends in the past, for this app, I wanted to leverage a serverless architecture. The required functionality wasn’t very complicated and I didn’t want to suffer the pain of maintaining a running server environment, worry about scalability/reliability, or deal with complicated deployments.
I had used Firebase on earlier projects in a more limited capacity, but knew enough about what it could do to make the decision that I would attempt using it for the wait times app. The service provides all manner of features under one roof, including datastore, lambda functions, users, push notifications, and analytics, all things I’d need. Add in the very reasonable cost structure, and it was a no brainer.
Mobile app
The last decision I needed to make was how to create the mobile app. My initial thinking was to try and get some more exposure to cross-platform tools by using React Native or Flutter, but after further considering how important it was for me to have a top-notch platform-adherent UX, I decided that it would be too much extra effort to not go fully native. Those tools are great at what they do, and for many apps, they are quite sufficient and yield massive cost savings. But if you want to live on the bleeding edge for a given platform, adopting as many of the first-party features as makes sense, it’s better to go native.
As it happened, SwiftUI was just being announced around the same time as when I was making this decision. I briefly toyed with the idea of going full SwiftUI, but after thinking on It further, I decided against it. SwiftUI at the time was still very new, not fully-featured, and would be in beta form until September of that year. I also knew I’d have to ramp up on some new concepts to get the back-end done, and I tend to try and limit myself to one or two large new things for each project. If you pile on too many new technologies for one project, you’ll end up spending way to much time learning and not enough time actually shipping. It’s great to learn new things, it’s part of the reason I pursue these types of projects. But, it can’t be at the expense of actually delivering a product, so I try to always strike a balance.
Next steps
At this point, I had defined project goals, outlined a basic feature-set, and assessed the feasibility of executing on the idea from a technology standpoint. My next step was to get to work building an MVP (minimally viable product) so that I could validate the idea in a real world situation. In the next part of this series, I’ll discuss how I went about creating my MVP, how I tested it, and what I learned.
