Launch HN: Mystro (YC S17) – Automation for On-Demand Drivers

[mrajcok]

Hi! I'm Matt from Mystro (http://www.mystrodriver.com) and we're in the current YC batch. We're building an app for on-demand drivers to automate the process of driving for multiple platforms.

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).

[chatmasta]

Are you worried about a cease and desist from uber/lyft for building a "third party client" that interfaces with what is effectively a private API? There is plenty of precedent for them to send you a C&D for that, as many companies do with third party apps (e.g. Snapchat is very aggressive). Beyond that, won't it be a constant cat and mouse game of making sure your app integrates with uber/lyft?

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.

[mrajcok]

We don't actually use their API.

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!

[chatmasta]

No, you may not be calling their API endpoints directly with HTTPS requests initiated from your own code. However, as I understand it, you're effectively pushing the buttons (or hooking the methods, idk android) within the Uber/lyft app, which causes their app to call the API endpoint. So you are certainly calling the API, just indirectly. Regardless, your app is definitely "automating usage" of the Uber/lyft app, and could therefore be in breach of their terms of service.

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.

[dustinls]

There would be nothing stopping someone from reverse engineering a private api using an android app and using those findings to write a third party app for iOS.

[koolba]

> My co-founder got the idea for Mystro while completing over 10,000 trips as an Uber/Lyft driver.

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)

[mrajcok]

He was a driver full-time for 2 years.

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.

[jsloss]

Saw your co mentioned in the Techcrunch round up yesterday. Sounds like you've found a great job to build a company around!

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!

[mrajcok]

Thanks! I agree with this, and we've actually seen many users buy Android devices just to use our app.

[jsloss]

I believe it. It's so tightly aligned with the progress a driver is trying to make, and I'm sure they're doing all sorts of ineffective work arounds / substitutions right now. Think you guys have a shot at defining a new category here! Good stuff.

[mrajcok]

Thanks!

[pj_mukh]

I've seen practically all drivers do this manually while grumbling! Great catch! Is there a trial period of sorts?

[mrajcok]

Thanks! All drivers can use for free with up to 10 trips a week, and there's a 7-day money-back window for the unlimited plan.

[pj_mukh]

Sick! I'd suggest expanding the trial period a little more Most drivers I've seen complain about their margins all the time. However, if they could try you for longer I have no doubt they'd see the savings, get hooked and gladly pay.

It'll also fire up your growth. Free month for a limited time perhaps?

[mrajcok]

Yes -- I think we're going to adjust this and also try to show them how much extra money Mystro is making them.

[toisanji]

Im surprised yc funded something like this. Its something that could fall apart at anytime if Uber or Lyft get pissed off, and now its an even easier target since its funded and a corporation now. They must have some secret magic to avoid the legal issues.

[TekMol]

One app can control another on Android? Which permission has to be granted for that? I cannot remember ever being asked "This app wants to remote-control that app. Are you ok with this?".

[mrajcok]

You need to give specific permission to the Mystro accessibility service for it to control the rideshare apps.

[shostack]

How do you go about marketing this? I would imagine advertising on driver forums. I'm curious if pitching in the car would work, but I wonder if you would get bad reviews.

[mrajcok]

We have a bunch of the top influencers in the on-demand space helping promote.

We've thought about pitching in the car but the cost doesn't work out.

[yannick]

sounds like useful software that could be someday be added natively into whatever the future OS of cars look(s) like

[mrajcok]

Definitely -- right now Android Auto is something we're very interested in integrating with.

[jsloss]

Paging Elon.

[ijustdontcare]

your technology is an Android App that remote-controls Uber and Lyft apps, and you charge 100$ per year for it

What makes you think nobody will sit down and rebuild your app in a week?

[tammer]

This isn't a great question, as the child comments illustrate; effectively its a proven tenet of startup culture that execution and growth are key steps to profitability rather than the uniqueness of an idea or service.

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?

[mrajcok]

We actually are solving a massive driver retention problem for them (96% churn) so we see ourselves as beneficial to the rideshare companies since we increase driver earnings and retention at no cost to them.

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.

[sharkmerry]

>>We actually are solving a massive driver retention problem for them (96% churn)

Forgive me, but how? Is downtime really the issue that makes drivers leave?

[jsloss]

They mention this issue on their site. It seems as if they're helping to reduce driver churn (which can be as high as 90% after 1 year) and thus Lyft / Uber let them rock and roll.

[yannick]

I think Hacker News should kick off every ShowHN thread with a comment from CouldBuiltThatInAWeekendBot

[jsloss]

That username though :)

[mrajcok]

We have a good understanding of what will provide the best driver experience based on a huge amount of user feedback.

There is also the potential to use the data we have to optimize driver revenue even further.