
Launch HN: Mystro (YC S17) – Automation for On-Demand Drivers - mrajcok
Hi! I&#x27;m Matt from Mystro (<a href="http:&#x2F;&#x2F;www.mystrodriver.com" rel="nofollow">http:&#x2F;&#x2F;www.mystrodriver.com</a>) and we&#x27;re in the current YC batch. We&#x27;re building an app for on-demand drivers to automate the process of driving for multiple platforms.<p>My co-founder got the idea for Mystro while completing over 10,000 trips as an Uber&#x2F;Lyft driver.<p>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&#x27;s settings so they do not have to look at&#x2F;touch their phones to accept trips while driving.<p>Currently, we support Uber and Lyft, but we are planning to add many more rideshare and delivery platforms as we grow.<p>We have found that using Mystro makes drivers 30% more money, reduces distracted driving, and makes driving much more relaxing for our drivers.<p>We run entirely on the user&#x27;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.<p>We have a SaaS business model and charge drivers $12&#x2F;mo or $99&#x2F;yr for unlimited trips, and all drivers get 10 trips per week for free.<p>We&#x27;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.

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

------
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?

