Launch HN: Mystro (YC S17) – Automation for On-Demand Drivers
My co-founder got the idea for Mystro while completing over 10,000 trips as an Uber/Lyft driver.
We automate switching multiple on-demand apps on and off. This ensures that drivers are available on all services to get the maximum number of rides but never get penalized for not accepting a ride because they are already on a trip. We also automatically accept trips according to driver's settings so they do not have to look at/touch their phones to accept trips while driving.
Currently, we support Uber and Lyft, but we are planning to add many more rideshare and delivery platforms as we grow.
We have found that using Mystro makes drivers 30% more money, reduces distracted driving, and makes driving much more relaxing for our drivers.
We run entirely on the user's phone and integrate with the driver apps directly, avoiding any need for API access and letting us easily integrate new platforms as we go forward. For now, we are only available on Android (which 65% of drivers use), since app-to-app interactions are much more restricted on iOS.
We have a SaaS business model and charge drivers $12/mo or $99/yr for unlimited trips, and all drivers get 10 trips per week for free.
We're happy to answer any questions about Mystro or about ridesharing in general (especially from the driver perspective).
31 comments
[ 2.4 ms ] story [ 69.0 ms ] threadWhat makes you think nobody will sit down and rebuild your app in a week?
There is also the potential to use the data we have to optimize driver revenue even further.
I have a similar but I think more valid question, however, which is how do you plan on staying compatible with the ride-sharing companies themselves, who I assume will eventually attempt to lock you out of their services as they come to see you helping their competitors?
We have a framework built out that lets us rapidly respond to app updates and a team of testers all over the US.
We have also thought about how to best circumvent any active attempts to block us -- since we interface with the driver apps directly rather than any APIs that would be harder to do.
Forgive me, but how? Is downtime really the issue that makes drivers leave?
It'll also fire up your growth. Free month for a limited time perhaps?
Quick thought re: your "Sorry we're not on iOS" page. You give some android phone options (great job at removing a barrier to use) but you leave the viewer with a bunch of uncertainty around timelines.
I driver needs to balance the idea of buying a new phone (and associated work arounds) with guessing how long it will be do develop an iOS app. There's friction there that will push most people to default answer "nah, I'll wait"
Providing some guidance on timelines, or otherwise overcoming the uncertainty around them would be super useful to the calculation / evaluation drivers will have to make.
Two cents.
Best of luck in your continued growth!
It's very telling that you don't have an iOS app, likely because the security model prevents this kind of integration hack without jail breaking, or if you're lucky, some creative use of URL schemes.
I know you say you're "helping user churn" for uber/lyft, but those companies are certainly not obliged to agree with you and can send you a C&D at any time (I would bet on it). I can't see how you can build a viable long term business on a hack like this, where you are effectively an unauthorized third party app subject to the whims and possibly lawsuits of uber/lyft.
If you get a C&D from either Uber or Lyft, your product and business model no longer work, unless you're willing to go to court or blatantly ignore the C&D and the law by circumventing any technical measures introduced to stop third party apps.
No offense, but I'm honestly surprised YC funded a company with such a fragile basis of operation. Unless the plan is to go to court and fight any C&D, in which case I'm certainly rooting for you to set a nice precedent for third party apps.
Overall though, it's a great business idea and solid MVP. Good luck and boola boola.
It's much harder to do UI automation on iOS -- it is more locked down.
We have a pretty robust tool to keep our integration working with any app updates.
Thanks!
I'm not arguing that there are no workarounds or hacks or backup plans to whatever technical obstacles Uber/lyft may throw at you. In fact I'm quite familiar with them from the iOS side. However, as a high profile startup and US corporation (funded by YC), you can't blatantly ignore a C&D just because you disagree with it. And you definitely can't introduce new hacks or workarounds after receiving the C&D. Your only option would be to fight it in court.
(Also consider the play store / App Store can remove you at any time without any legal due process, and will likely do so when notified of noncompliance of a C&D)
Don't get me wrong, I think a court battle over this kind of client-side integration is sorely needed. But as an investor, I would be concerned my money would end up in a lawsuit before the app even gets traction. If you're planning on a lawsuit, you might actually win it.
Incidentally, if you're taking the attitude of circumvention, then you could "go all the way" by asking users to sideload (via 7 day developer certs) a custom version of the Uber/lyft apps that includes code to interface with your app. That's the approach I took to automating iOS apps in the past, but that was on jailbroken devices. Side loading presents a hard usability problem, but I bet you could convince users to plug their phone into their computer every 7 days.
We've thought about pitching in the car but the cost doesn't work out.
Wow that's nuts! Over what span of time was the 10K rides?
At 20 minutes per ride and 8 hours of non-stop driving per day, 7 days a week, that's almost a year and half. Add in any breaks between rides, weekends, or dead time between rides and its even longer.
> We automate switching multiple on-demand apps on and off. This ensures that drivers are available on all services to get the maximum number of rides but never get penalized for not accepting a ride because they are already on a trip
Had to read this a few times to parse it. So do you guys repeatedly cycle through the apps so the driver is on/off repeatedly? Or is it permanently off and you turn it on when you detect that there's a ride to accept? (Which I don't understand how you'd do if it's off)
When the driver is not on a trip, we turn on both apps. When they are on a trip, we turn off the app not in use.