After we decided to take a shot at building a different kind of IoT platform, we came up with a rough plan:
- precisely identify the intended audience
- focus on a few key features, leave out everything else
- hypothesize at least something resemblant of a business plan
- build it
We decided to proceed in this order because we feared building a flashy over-engineered thing that hardly anyone would find useful.
Creating Connhex has proven an exercise in staying focused: given our finite resources, we have been cutting features relentlessly. A clear definition of the intended audience was our north star in deciding what to double on right now and what to leave for the future.
Audience
The initial version of Connhex was built around two types of customers:
- companies that create connected hardware products
- software houses, agencies and developers. They typically have with great expertise in building apps, but don’t want to deal with the hassle of low-level communication protocols and infrastructures
While those two worlds seem very different, they do have some commonalities. Above all, the need for abstraction - even if in different directions.
Hardware companies do a great job with moving electrons around silicon. That’s their trade. So we shouldn’t expect them to be willing to learn how to orchestrate containers.
Designers have great taste and know how to make any UI feel intuitive. Why would they need to be bothered with managing UDP packets retransmission policies?
Given this is who we are building for, what should we build?
Key features
Jeff Bezos famously recommended focusing on things that don’t change over time. This seems an obvious concept - but it’s a tricky one to get right.
As you start building, new ideas start to come up - it’s really easy to give in to temptation and just implement that additional feature. This seemingly harmless fact is actually dangerous:
- your schedule will be pushed around
- your product will lose cohesion
- you won’t focus on polishing enough the core features of your product
We are guilty too. We said “wouldn’t it be great if Connhex also…?” countless times. And we, indeed, started expanding Connhex and postponed its launch multiple times.
On the flip side, we were able to keeping Connhex’s core cohese by getting a few pillars - key for our audience - right. As boring as that sounds, that’s how we came up with something that actually works. Let’s dive into these pillars a bit.
Security and reliability
When you are handling potentially sensitive data, security is a must. Breaches can always happen, but your solution should tick as many boxes as possible nonetheless.
The same holds true for performance and reliability. The best products are the ones that “just work” - and behind that simplicity there’s often an awful lot of work.
Cost effectiveness
If you’re planning to serve small-to-medium hardware manufacturers, cost effectiveness is a must too. Creating their own IoT platform may be an investment entirely subsidized by their profits - already stressed by the current chip shortage. In order to have a reasonable payback period, the initial investment and the recurring costs should be reasonable too.
Ease of use
This one is too generic to be precisely defined - what’s the threshold that defines “easiness”? So let’s just give some examples.
While asking to launching a script to setup everything may be fine, manually editing YAML files is not. Similarly, requesting a user to setup its own docker registry is off-limits, while copying a configuration file to an edge device is reasonable.
Ease of use, cost effectiveness, security and reliability were the highlights that subsequently drove our engineering choices. Part II of this post is coming soon: we’ll discuss a few engineering decisions and how we are selling Connhex. Make sure to subscribe to our newsletter to hear that story.
Want to learn more about Connhex? Just visit www.connhex.com or get in touch with us!