Windows mobile app or Windows 8 support?

  • 125
  • Idea
  • Updated 2 years ago
Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members.

Do you have plans to support Windows mobile or tablets that have a full Windows 8 OS?

Cheers,
Photo of Eagle One

Eagle One

  • 1,854 Points 1k badge 2x thumb

Posted 5 years ago

  • 125
Photo of Thejo

Thejo, Alum

  • 1,120 Points 1k badge 2x thumb
Official Response
Hi Daniel,

The lack of support for Windows Phone is due to a lack of resources and probably not due to any technical constraint (we haven't really spent a lot of time investigating the capabilities of the platform to say that definitively). Fitbit is creating an app for the Windows platform 7 years after they launched the product! It's hard for a startup like Automatic to justify the significant investment involved in developing for Windows Phone when the market share just isn't there. We're grateful for the interest we're getting from Windows Phone users, but, at this point, it's still not enough for us to build for that platform. We're always motivated to deliver the Automatic experience to more users, but we also have to constantly ask if the trade off makes sense.

We really want to build for Windows Phone, but can only do it when we feel that the number of users we can expect justifies the effort involved.

Thanks again for your interest in Automatic.

Thejo
Photo of Adam Altman

Adam Altman, Alum

  • 3,712 Points 3k badge 2x thumb
Official Response
NOTE: This post was inspired by a private conversation thread with a member of this community who seemed to find the explanation helpful and informative. Large sections of this post are reproduced from that thread. To that gentleman, thank you for taking the time to engage and help me understand your frustrations civilly.

----- Dec 21, 2014 -----

Community, 

I’m Adam and I currently lead product efforts at Automatic. 

I want to address this thread and the many recent frustrations, curiosities, and desires within.  Firstly, I’m sorry we’ve caused you to be so frustrated. Secondly, we do hear you. And the greater the number of people asking for this gets the closer we'll get to conviction that we should and have earned the right to support Windows Phone.

This post is not going to make you a promise that we’ll build it. We do not have any set plans to do that right now.  But given the fervent conversation, I do feel you all deserve a respectful explanation of how we make decisions, the tradeoffs we need to consider as a business, and why that’s led to not making a Windows Phone app yet. The intention here is not to be defensive, but rather to provide clarity in hopes that that will alleviate the understandable frustration of just not knowing why the heck we don’t do it already. This post is also not an attempt to get you to stop asking us for it. Please ask.

For what it is worth, I would like us to support windows phone in time. And I am exploring creative ways to get there sooner than later.

TL;DR
The software+hardware development process is not very transparent. It costs a lot more than anyone could reasonably expect for us to deliver and maintain our experience on a new platform at a quality level we can be proud of. And the complexity of supporting another OS could slow down our ability to refine the product.  Right now, we need to move fast because we owe it to our existing customers and have not fully delivered the automotive future we believe deserves to exist.  All of this is in the context of threading the delicate financial needle of being a startup, where the stakes are higher. Though perhaps unintuitive, I believe we need to earn the right to support another OS and are not there yet.

Why Not Yet?
We’d like to be able to give you what you want, but thus far have not been able to find the bandwidth and resources to make it happen given the tradeoffs we have to make as a small startup.  To invest time in a new project, we need to know that it is among the best possible uses of our time and money, or we don’t get to survive. There are two major components to this: payoff or ROI of the effort atomically, and the new program’s impact back to the company holistically. Let me talk about the two in turn.

Taking on a new platform is a huge commitment for a company. There's a lot of work that goes into every release of an app--engineers, project managers, testers, graphic designers, marketing, customer support, and managements time. A first release especially would take an unusually large effort because of all the testing that would need to be done and the inevitable bugs that would come up. You can put the cost in the 100s of thousands quite easily.

Additionally, porting over one time would not set us up for success on a brand new platform. Rather, we would only release a Windows Phone product when we could support it as an ongoing program across all those functions I mentioned.  Otherwise, the product we put out would quickly become out of date, users would be frustrated, our service level to you would sink, and we would be making waste of earlier efforts to deliver it in the first place.

Some examples: When we release new firmware to our devices that can require client app updates. When we introduce new features, we would want to keep Windows at least in lock-step with the iOS and Android apps. When microsoft makes some changes to the OS, or a new phone with a new form factor/resoltion/set of sensors comes out, we'd again have to adjust the app just to keep it working as expected.  Throughout, we would need to train up some of our customer support people to know the windows phone platform and our app on it inside and out, so that they could answer the inevitable questions that would come in from users. They would need to be ongoing fulltime hires, or else be taking ongoing bandwidth away from the short staff we have already. The same would be true for the entire team eng/design/marketing/etc) involved that I listed out above, as each would continue to be involved in the program long after the first version were released--forever, basically. 

Based on the above, I estimate the fixed cost of a high quality Windows Phone program at near or over $1M a year. I may be off by some factor, but the point is not to pin down a target for nuanced scrutiny. Rather, the directional message is what I hope to convey: it’s incredibly expensive.

At a bare minimum, projects must not lose money. If we examine what it would take to breakeven, we would have to sell tens of thousands more units each and every year as a direct result of offering a Windows Phone experience. Remember, our hardware has cost to it and our retail partners take a hefty cut as well, so each sale of our $99.99 device provides just a fraction of that back to the company as unit margin to offset the cost of design, development and support. 

But breakeven doesn't actually cut it for us because we're working with limited funds to make the best investments that we can while trying to keep the company moving as fast as possible. There are other projects to consider that each have their own expected impact and spinning up one more means either spending more money than we planned to or taking resources away from some of the others. In an ongoing sense, any windows phone program would need to be generating millions of revenue every single year (and you only buy the device once!) to make sense to commit the capital, time, and people to it just to break even. To be one of our strong investments, probably $10m +.

Those are ballpark numbers, not meant to say we've done a rigorous analysis yet. But hope it gives you more context about how we have to think about this. If it’s not clear yet, we believe it’s a stretch to expect the Windows Phone community to fall in love with us en masse and justify these kinds of volumes.

Even if there were the volumes, one final perspective to consider is the cost of speed to our company of supporting another OS—and whether we’ve accomplished enough as a company to earn the right to do that. Most folks who’ve developed mobile software will tell you that adding another OS causes you to move slower on all fronts, as each will provide constraints to the overall system which have to be addressed for major releases that make breaking changes to the shared backend. 

Maintaining speed is most critical to us in the early phase of our company’s growth, while we still have to figure out the exact problems we’re solving, for whom, and how our product direction should evolve. For instance, there are things we feel we owe our existing customers still that we haven’t delivered as fully as we would like to. Taking resources away from that simply to gain more customers is not an approach we could feel good about. Though many find value in Automatic today, we’ve got a long way to go to execute on the automotive future we think should exist.  And as we experiment with that, we need to be ultra-lean about how we get to each next proof point.  In fact, beyond the question of whether there’s enough demand to support another OS, we really may not have succeeded enough yet to deserve to. 

Instagram famously did not support anything but iOS up to the time when they had about 30million users. I believe something close to what I’ve said was a driving factor for them.  Once they started supporting android, it took a year and 120 million more users before they supported windows phone as well.  To this day, Instagram, one of the biggest apps on the planet, does not support Blackberry, Symbian, JavaME, or Ubuntu—though I’m sure there are a least a million people who want Instagram for each of those OSes.  This is more than enough proof of demand, justification for the cost a teams time, and they are not wanting for financial resources now that they’re in the Facebook family. So there must be another factor at play; I would posit that it is in large part this balance of maintaining speed vs serving more users.

Through this lens, as we achieve more scale and product maturity over time, the cost of adding on a new OS will actually go down. That fortunately coincides with what I imagine will be more widespread education about the benefits of connecting your car, a potentially growing Windows Phone user base, a growing Automatic base that can support a larger team to work on more projects, and getting past the ultra high priority projects that are taking up our resources and bandwidth now. In short, as time goes on, every single factor involved will tend to make the case to build for Windows Phone more compelling.

What we can do.
All of the above is meant to explain why we have not built a Windows Phone app yet.  It doesn’t mean that overcoming the admittedly challenging gauntlet laid out above is the only way to get you something.

I don’t want to get hopes up prematurely.  There isn’t a plan at the moment for anything Windows related.  But I do want you all to know that I am having conversations with our team and certain partners to see how we can get you something tangible sooner than later: either a pathway to get you a solution, a way to help get us more quantitative conviction around the demand, or the technical unblocking so that someone could independently build this. We are exploring ways to let third parties access our hardware directly, for instance. That’s not available now (and may never be), but if we do, then there would be more than one way to get to a solution.

Other solutions. 
As a show of sincerity, I'll point out a fact that many of the recent posts have noted: an OBD-based driving assistant called Zubie did release a windows phone app last week:  http://www.windowscentral.com/zubie-wants-make-your-driving-safer-and-easier

Our products have some significant differences, and we of course believe ours is superior, but fact remains we're not enabling you to have it yet. If you are dying for a device experience that works with your setup, it's a viable option you can buy today. I’m not endorsing their product, business decisions, or attesting to the quality of data and application experience they provide.  Just acknowledging that it exists.  One VERY Important disclaimer on Zubie that many seem to miss: they have a required $99 per year ongoing service fee (first year included in the purchase).  Our Link product does not and never will have fees beyond the initial purchase. That’s not a disparaging of their business model but instead providing a level of transparency that we believe consumers deserve.

Final Thoughts
I hope this reply is more satisfying than upsetting. I’m sure to have said some things that one could point out as imprecise, find counter-examples to, or otherwise take down if the goal is to do just that.  We’re trying very hard to make something brand new work in the world and are in the early innings.  We will not be able to please everyone—ever, in truth, but especially at this stage.

I cannot necessarily give you the thing you want right now, but I'm trying to deliver on the important goals of treating respectfully every person we deal with and being transparent about our doings. I ask only that you please return the respect when letting us know what you wish we could do.  Our dear community agents at Automatic are not the ones who get to make the call on product roadmap, but they do have to take the brunt of some uncharitable phrasings to otherwise very desired feedback.

To end on a positive note, I really really really do want us to be able to support Windows Phone.  Hope this makes things a bit clearer.

Happy Holidays,
Adam