Problems with Estimote

estimote-batteryIn the world of Bluetooth LE, Estimote has become synonymous with beacons. Through brilliant promotions, fantastic product shots that have appeared on every major technology blog as the accompanying “beacon photo”, and more than 10,000 developer kits delivered worldwide the company is a Y-Combinator superstar.

But while the company has never claimed to be at any stage other than a developer preview, persistent problems and questions are cause for concern: because for now, as Estimote goes, so goes a wide swath of opinion about what we affectionately call the becosystem.

Estimote Is A Major Success

First, let me say I’m thrilled by the success of Estimote. It’s hard to fault them for not anticipating how the iBeacon industry would resemble a tsunami. They represent the potential of the proximity industry as a whole and have set the bar in how that industry is promoted and packaged.

Start-ups always dream of hockey-stick growth curves. But even Estimote would have had a hard time anticipating how we’d go from a standing start with the launch of iOS7 to major brands rolling out thousand of beacons a few months later.

Estimote is in the enviable position of needing to act like an established player in an industry that popped up over night.

Customers and developers expect them to act like and have the resources of Google or Apple. Their promotions and press coverage certainly make them seem big and polished and established.

But as you peel away the marketing layer there are persistent problems that are, at the least, irking developers.

Estimote has rushed to open offices in at least 4 major cities (most of them, it seems, focused on business development), is scrambling to build out its systems, and has a back-log of orders and anxious developers who don’t want to miss the iBeacon bandwagon.

They’re still in an enviable position. There’s lots of time for corrections.

But while there are some short-term issues that have obvious corrections, there are much bigger questions that might strike a note of extreme caution for anyone planning to build a service business around their turtle-shaped beacons.

Get Me My Estimotes

estimote-shipping-problemsOne of the biggest challenges for Estimote seems to be production. Orders exceeded capacity in late 2013 causing a delay of up to six weeks. They now promise 4-week delivery windows for new orders according to responses on their Facebook page.

Estimote’s response to the delays was to ask for understanding: they’re still working on a pre-order model. This is an understandable tactic for a start-up that doesn’t want to run production costs ahead of demand. And so they only do production runs based on actual orders in hand.

Last week, Alex Santos responded to concerns about the delays in shipping (emphasis added):

I appreciate your analysis. We are on a pre-order model at this time so we expect customers to understand that there may be a delay to ship times. We have shipped a great deal of beacons in a timely fashion but there are customers who are still patiently waiting, which we sincerely appreciate. We have an SDK and an app that can help developers employ a virtual beacon (through our free app) to begin their development cycle until their beacons arrive.

Again, I completely appreciate the question, I do see your point but at this time we are still offering dev kits inside the paradigm of a pre-order model. I am confident that we will move away from this model but we are still maturing vectors around the hardware to reach that level. Thanks for raising the concern.

No, Alex. You can NOT expect customers to understand.

The beacon industry is NOT on pre-order, it’s on deployment. You have $3.2 million in the bank. I’d expect by this point that Estimote would either be producing beacons ahead of the demand curve or be able to do a lot better job using predictive analysis to anticipate production runs.

And I’m not sure what “maturing vectors” refers to? Does anyone know?

But perhaps what’s more frustrating than the shipping delays is the inability to actually track your order. Some kind of dashboard might help. Instead, the Estimote Twitter and Facebook timelines are littered with requests for confirmation on orders and promises to respond by e-mail.

So hang tight, everyone. When you order your Estimote, it’s put into the next production order because – you know, they’re still too small to just produce ahead of the demand curve. Which would be fine, I suppose, if I couldn’t order and receive beacons from other providers with 3-4 days notice.

Just Change the Battery

Our own experiences with Estimote date from the earliest days. We received a set of beacons from one of the first production runs and they had a bug in their firmware which meant the battery ran out in 2 weeks. Bugs are to be expected in an early release so that wasn’t a problem.

But it DID give us an important insight. To replace the battery, we needed an Exacto knife and some crazy glue (see the photo at the top of the post) – and it felt almost tragic to disembowel the beautiful packaging of the Estimote.

It reminded us that you DO need to treat Estimote as disposable – and come up with a plan for replacing them entirely when the retail chains you’re servicing have ‘motes whose batteries run out. For developers, this is a key question: will Estimote provide a ‘replacement’ policy for beacons whose batteries drain before their time?

Fleet Management, Security and Content Management

This week, Estimote launched a new version of their virtual beacon to the Apple app store allowing you to toggle the signal strength so that when you’re testing your app you don’t need to walk 100 feet before interactions occur and provided over-the-air firmware updates.

It’s a great addition to the virtual beacon.

But perhaps more important, they launched the ability to change the UUID of your beacon – something they resisted at first but eventually gave into following a discussion on GitHub.

But this update came up somewhat short – because the demand for securing your beacon from ‘spoofing’ and the need to authenticate ownership will have to wait for a future release:

There is not yet beacon ownership authentication in the current firmware. That means that anyone can change the UUID of your beacons using our SDK. Authentication is coming soon in a future update…

If you are building a mission critical app where security is important please make sure to implement security on your end. You can use our SDK to rotate the UUID or combine it with other signals, e.g. from GPS. We plan to publish a security layer in a future firmware release. When it becomes available, you will be able to update your beacons with the Estimote iOS App.

Estimote is also a week or so away from launching a “very early stage” version of a content management system, about which you can find out more by contacting them directly. How robust this system is, I guess we’ll have to wait and see.

The Strategic Issues With Estimote

At a much higher level, however, developers and partners need to take stock of several unknowns and make informed decisions about what these unknowns mean for investing development time in the Estimote platform.

There Is No EULA or Software License

Again, unless I’m missing it, there’s no current license for Estimote. Without knowing what warrants, restrictions or rights Estimote is demanding of developers, you’re in a legal grey zone which might take you by surprise once it’s released. In theory, Estimote might require you to ‘pass along’ certain terms and conditions to your users, they may reserve rights to aggregated location or usage data or analytics, or may require you to use their SDK and back-end as part of their service.

There Is No Pricing Structure in Place

It’s unknown what Estimote will charge in addition to the costs of the beacon, if they charge anything at all. They may allow “free” use of the beacons and charge for optional back-end services. Or, like Qualcomm, they may require you to use their back end services and charge monthly fees or fees by volume of users.

Estimote is Competing With You

Estimote is meeting with major brands and retailers. They may be (according to some accounts we’ve received) providing road maps and services that compete with what developers are building around their beacons directly to the companies who you hope will be your future customers.

Certification and iBeacon Compatible

No one knows what Apple’s final iBeacon specification will look like – and it’s unlikely it will have much of an effect if any on beacon developers. We don’t see this as a major issue, yet it’s worth noting. What might be of more concern to your legal team, however, is whether the beacons you’re putting up in stores are FCC, IC or CE certified. While it’s unfair to expect that a developer kit would have these certifications, you might want to consider the timing by which it will happen before you start planning large-scale roll-outs.

We’re In This Together

Estimote is the flag-bearer for the industry. For now, they’re still the poster child for what a iBeacon can be in the public imagination.

On January 4th, Estimote said they were 2 weeks away from an important release. Three weeks later, they’ve launched a new virtual beacon and some tweaks to their SDK.

My own predictions seem to have fallen flat. In fact, not one of my predictions came true – other than my idea that a “basic CMS” was on its way. Instead, I’ve found myself looking at Lighthouse or Beaconic for examples of the kinds of systems that can be built in astronomically short time frames.

But we’re all in this together. Estimote is still the company to watch if you’re looking for one of the places that massive scale adoption of beacons can become a reality. But as they say in about the stock market we’re recommending for now at least that you treat Estimote as a ‘hold’ rather than a ‘buy’.

What has your experience been? Has Estimote exceeded your expectations? What do you wish they’d solve as you figure out your own strategy for a beaconized world? Drop a note in the comments below or drop it to me anonymously via e-mail (doug @ mylocolo.com).

Give Us A Follow

Join our weekly e-mail list for more on iBeacons. Check out our Twitter list to follow the best beacon tweets. Check out our BEEKn Google page and just generally stay in touch!

22 Responses to “Problems with Estimote”

  1. Hi Doug,

    thanks again for your article and an important discussion around major challenges most of software/hardware startups like our deal with.

    Let me comment on each and every topic you mentioned separately.

    SHIPPING
    We are a lean-hardware startup. We have launched in July 2013 and are shipping since day one. Our high capacity factory (http://www.youtube.com/watch?v=xCHmu_KEemg) is just 10 minutes from our R&D office in Krakow and we keep iterating on the product based on the feedback from developers. Current lead time for beacons production is aprox 4-5 weeks and we can produce any number, but as you know iBeacon spec is not finalized yet, so there is no reason to manufacture millions of them now. We ship internationally and the reason some people are still waiting for their beacon ordered 1-2 months ago is mostly due to the paperwork or payments problem for some countries.

    BATTERY
    Beacons we sell now are evaluation Dev Kits. We test form-factor, signal strength, battery life and the software. Some batch of beacons we shipped were affected by a software bug that due to the lack of reboot after firmware upload in the factory caused high power consumption. Hackers and tinkerers who experienced that issue just replaced the battery what rebooted beacons automatically, so they can work for many, many months. We are also working on an advanced power management settings to be included into one of the next firmware releases.

    SECURITY
    Developers who received their dev kits and are tinkering around are the pioneers building the next generation of mobile apps. Some build simple loyalty programs, indoor location apps, contact-less payments or other mission-critical applications. We pay attention to their feedback and constantly improve both beacon as well as an app communication security. At this moment developers are able to change UUID, so some of them are implementing own secure layers.
    We will release our implementation soon and beacons can be upgraded using our most recent iOS app.

    COMPETING WITH DEVELOPERS
    We do of course meet major brands and retailers to educate on beacons and listen to problems they plan to solve with Estimote technology. But we don’t expect to solve all these problems ourselves. Retail and other real-world industries are trillions dollar market opportunity. Note that 94% of all transactions still happen in the physical world (Amazon, eBay, etc is still just tiny percent). That’s why we offer full SDK, rich APIs, demo apps and responsive help desk including community forum http://community.estimote.com/hc/en-us. We are developers-oriented company and our goal is to provide developers with the simplest possible tools to educate their customers, build their contextual-computing apps and focus on their domain specific problems when deploying beacons.

    CLOUD API AND CMS
    We are inviting to beta tests of our Cloud API and web-based management tool that will enable developers to manage fleet of beacons and manipulate with the content assigned to regions. We expect there will be also plenty of single-purpose CMS systems for different applications like airports, hospitals, retail and beyond and we hope some of them will use our Cloud API to take most of our beacons accessing temperature date, battery level, over the air update, secure layer, etc.

    BULK PRICING
    We keep selling dev kits and there are thousands of developers testing them in the field. We talk to them and sometimes they share with us results of their installations like Prophets museum http://prophets.be/work/#/ibeacon Those developers who demonstrated an ability to build great apps and validated experience with their end-users often back to our business teams in US and Europe to negotiate bulk pricing for FCC/CE production-ready sets of beacons they plan to deploy at scale.

    I hope we managed to clarify most of the issues and we are also looking forward for feedback from all of you who participate in the discussion. You can always reach out to our Community team sending an email to contact at estimote.com or reach out to me directly using email address from the Dev Kit or our website: http://estimote.com/about-estimote.html

    Reply
  2. Jakub:

    Thanks so much for your response. If I can clarify a few things:

    SHIPPING:
    I get it. I understand. I highlight the issue as one that we hear about almost weekly – we receive dozens of e-mails from the beacon community and it’s only about Estimote that we hear the same thing: “I ordered them weeks ago and I still don’t know when they’ll arrive.”

    I understand you don’t want to do production runs too far ahead of the curve, and I can only imagine the challenges of shipping internationally. But even in Canada we’ve heard the same refrain: “Wish I had mine, I have no idea when I’ll get them”

    Some kind of better dashboard might help no? Sometimes it’s not the delay that’s the issue, it’s the not knowing.

    BATTERY
    I have no issue with your battery life, as I indicated in the post. But developers need to consider that when the battery runs out they’ll need a new Estimote – you absolutely should NOT be telling people to “just change the battery”, as we were told to do. I can’t imagine telling, say, 100 retailers to grab the crazy glue.

    I don’t have an issue with this – your form factor is part of the appeal. But the form factor is a tightly enclosed case that doesn’t allow easy battery swaps.

    On another note, however – I wonder if you could publish an engineering assessment of how long the batteries will last when the Estimotes are set to different signal strengths?

    SECURITY
    No worries. Just saying that there’s people waiting. :)

    COMPETITION
    Great.

    CLOUD API/CMS
    Can’t wait to see it!

    BULK PRICING
    Awesome.

    BUT….
    You didn’t answer these key questions. Or…can you provide timing for when you’ll announce?

    – When will you release the software license agreement and any applicable EULA terms?
    – When will you announce your pricing – will it come with the launch of the Cloud API and CMS system?
    – Do you have an anticipated date for FCC and other certifications? At what point will you “lock in” your beacon as the ‘certification version’?

    I really appreciate everything you do for the ‘beacon community’. Because of Estimote you’re giving developers an amazing tool to start dreaming up amazing uses for beacons.

    Keep up the good work – it must be challenging keeping up with your growth. But DO understand that there are entire businesses emerging because of your work, yet those businesses and decisions related to them are hobbled to a degree because timing, costs and terms are unknown quantities.

    Reply
  3. Nilton Heck

    Hi Doug,

    Thank you for your post. I’m new into this Beacon thing and you helped me understand (and actually see) some issues i was concerned about.

    Well, this whole thing about iBeacon is pretty new. So, in one hand i does not feel so bad about waiting some weeks to receive mine. But, in the other hand i see myself tied – without even an idea about when i’m going to actually touch the real device.

    But despite to my quoted points above there’s something you wrote that made my neurons run crazily around my brain: the idea of Estimote competing with developers. It just isn’t fair, mainly into this early stage when developers are crafting some ideas.

    For me, as a developer, it seems that Estimote haven’t faith that they can be profit work only as a supply business, like api providers usually does.

    Into this early stage it is very comprehensible that Estimote need to create use cases but use cases are completely different from fighting for space with developers. In my opnion the contract between developer and Estimote should be very clear. This way the ecossystem around Estimote would be much more transparent.

    As a future investor on iBeacon: transparency is gold. Which company i’ll have by my side to help me deliver to customers good results? Estimote sounds like an awesome choice, but need to improve here and there.

    Reply
  4. Thanks Nilton for your comment.

    I take Jakub at his word: they are only educating retailers and brands.

    Look at it this way: some large brands ARE developers. They have their own in-house teams, etc. So, Estimote is “pitching” them just like they might pitch ANY developer.

    But what has struck us based on the feedback we’ve heard is that there might be a difference between what Estimote is communicating to these larger clients on the one hand and the developer community that’s a major focus on the other.

    We speak with a LOT of people, so we have a pretty good idea of how things are being positioned – and so we echo your comment about transparency and equality.

    I love that Estimote is saying they’re only educating retailers and brands. Our only caution would be that they may want to consider making sure that the degree of information they provide is comparable to what the 10,000 strong developer community receives.

    It’s their call of course – and a tough balancing act! But one they might want to think about, and think about how they communicate around.

    Reply
  5. Thanks for this post, Doug – I was starting to think I was the only one having a problem with delivery. Being a startup, I think everyone expects that there may be delays and problems. But I think there’s also an expectation that when there are issues, the company will be proactive in advising their customers.

    Before I reached out to Alex earlier this week to check on the status of my order, the last communication that I’d received from Estimote was November 3 when they advised my beacons should be shipping shortly. I don’t know that 12 weeks qualifies as “shortly”. I’m certainly happier now that I’ve been told my beacons are shipping next week, but better communication would have prevented some aggravation in the first place.

    Reply
  6. Thanks Sam –

    We did too. But we meet with so many people each week, chat by e-mail or phone, and the same things kept popping up.

    We thought it useful to help people know that while everyone is very supportive of what Estimote is doing, it can create a lot of anxiety not having answers to a few key questions.

    Reply
  7. hernando

    I think if you are a developer your best option is to go for stand alone BLE Beacon hardware supplier, there a lot cheaper and you can built your own backend CMS and APIs.

    Hernando

    Reply
  8. Juan Villalba

    Why don´t we go “beacon agnostic”, and focus on the communication, insted of the beacon piece of hardware?

    Reply
  9. We’ve test driven tod, estimote, a homegrown BLE112A-based beacon and Gimbal from Qualcomm and we’ve decided to go with Gimbal, for now. Their SDK, APIs, security and management are by far the most robust we’ve seen. They charge a fee per-access for APIs that is reasonable and the Series 10 beacons are cheap ($5). Just an FYI.

    Reply
  10. Such a big deal is being made out of the hardware..agree with Juans comment above..we were able to get beacons into our offices in India from China for $5 a piece…not bad when you are doing R&D..s

    Reply
    • We’ve had similar experiences with Estimote as well & decided to go with pure iBeacon makers. (1) No FCC, CE certification (2) Unclear on where they’re going; can’t simply “trust” that they won’t compete with us, as we’re targeting Retail as well (3) They appear too self-assured

      Vijay, would appreciate if you can share the manufacturer’s info. Thank you.

      Reply
  11. Benzartinho

    Hi Doug, I am very interested by ibeaocn technology and their use in marketing , I hada question, what is the advantage offered by estimote compared to other competitor

    Reply
  12. Shipment time was fairly quick for me as of March 2014. Dev Preview Kit ordered and received within a week. All units working per app trials. Now to dive into the SDK.

    Reply
  13. Stanko Vujovic

    I think Estimote can’t scale. They started in the best style, they do great marketing, but for me it seems like they simply dpn’t have people that really can move the product forward. it is still a toy mode. Issue with “fantastic glue” is a great example. to be honnest I stopped to belive in Estimote, and I see competitors getting stronger and stronger. Sad.

    * may negative opinion may be strongly affected by poor product expirience and the feeling that they just don’t care.

    Reply
  14. Tom Crown

    Interesting to read these comments on Estimote a year after the article has published. I tend to derive a lot of insight from how a start-up and its founders interact with and treat potential strategic partners and customers. When I reached out last year to Estimote’s founders asking for a brief call to discuss a number of strategic partnerships that could have solved some of these issues, my emails were relegated to a highly capable and hugely inexperienced young lady with an arts degree received in 2013. After what I felt like an enormous effort on our part to reach founders and a great stonewalling by the company in the form of cookie-cutter responses from this junior assistant my colleagues and I decided to look elsewhere. Not sure what’s in store for Estimote, but our first experience with the developer kit and the company did not leave us impressed.

    Reply
  15. I have been working on an app in last 3 month choosing Estimote solely based on their YC support.
    but I am looking elsewhere now because
    30$ per beacon is too expensive. even in bulk pricing 25$ is still too much.
    the level of analytics as of now is nothing more than number of pings.
    the level of support is questionable. (number of pings and thats it).

    Reply

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>