Earlier quoted context omitted.
I think dunking on the rpi is harsh - if it allows you to prototype and get your small-volume product out the door quickly, there's lots of other areas you could optimize the BOM first. Better to make a product with 75% gross margins as a single dev in 6 months than a product with 80% gross margins with a team of 6 in a year. Of course, they also overhired and wasted money on other BOM components
The problem with rPi is storage and filesystem. You need to issue a shutdown command and wait for it to complete before removing power in order to help ensure that it will come up without problems. This will literally never happen with a consumer IoT device. Also, SD media is extremely prone to failure. It's fine for prototype at a very early stage, absolutely not fine for something you ship to a user.
Taking over a Dead IoT Company
51–60 of 213 posts
Re: Taking over a Dead IoT Company
#52Hello, author here. Happy to answer any questions! My apologies for the downtime, I wasn't expecting much traffic today since I submitted the post to HN yesterday but I've started scaling my server now!
Once the new server was up, did any signs from the field connect to it?
Do you know how many signs are out there actively looking for the mothership?
Re: Taking over a Dead IoT Company
#53But hardware startups are brutal. Kickstarted hardware is torture.
Even experienced and well capitalized tiny teams go through this. A friend did one, rapidly realized the only option was to somehow get Chinese manufacturers excited about a small run of a strange product. Then two years later was trying to QA injection molds from across the ocean and switched manufacturers two times.
They delivered, but only after years of what must have felt like crawling over broken glass.
Maybe the NYC Train Sign team realized they couldn’t profit from the sign itself, but, unwilling to let the viral moment pass, were going to use it to establish themselves in consulting. You know… sell pickaxes.
Re: Taking over a Dead IoT Company
#54Earlier quoted context omitted.
The problem with rPi is storage and filesystem. You need to issue a shutdown command and wait for it to complete before removing power in order to help ensure that it will come up without problems. This will literally never happen with a consumer IoT device. Also, SD media is extremely prone to failure. It's fine for prototype at a very early stage, absolutely not fine for something you ship to a user.
On the other hand, see https://news.ycombinator.com/item?id=33892009 , https://www.raspberrypi.com/success-stories/korg-synthesizer... for example on how some companies use Raspberry Pi compute modules in their products. Am assuming here that they're adopting strategies to minimize/work around the problems you mention.
Re: Taking over a Dead IoT Company
#55Towards the end of the article the author mentions not wanting to pursue this as a business as there are so many cheap programmable signs out there already. As someone who would love to buy one of these and customize it for myself does anyone have experience or recommendations with any of these?
Some experience. The cheapest and easiest route is to buy a pre-made sign from AliExpress and just use the serial/usb interface to send data to the sign. That's somewhat limited, as you can't really control each pixel in a real time way, and you're limited to sending a series of "screens" as either text (in their limited choices of fonts) or images, defining some linger time, transitions, etc. With some visual disrup…
Re: Taking over a Dead IoT Company
#56Earlier quoted context omitted.
The entire project looks like the result of a high school student's first Instructables. It's hilariously under-engineered and it's clear that these folks had absolutely no idea of how to build a product, IoT or otherwise. Hint: if your product plans involve a raspberry pi, you probably fucked up.
How would you get a quick MVP of PCB + needed interfaces? I'd love to know if there is a PCB design as a service + manufacturer that allows small size of order (as a 3rd party integration). I think they definitely exist .. I just have to figure out who to talk to first.
Re: Taking over a Dead IoT Company
#57> With full control of the domain, we can create a new API based on what the sign is expecting and revive all of the signs that are out in the field. Once the new server was up, did any signs from the field connect to it?
Re: Taking over a Dead IoT Company
#58Maybe it’s very North American of me but I cringe when the author says “bad team”. Objectively, they didn’t have the skills, experience, or advisors to do this thing. And if the money truly disappeared, then someone crossed over into “bad” territory. But hardware startups are brutal. Kickstarted hardware is torture. Even experienced and well capitalized tiny teams go through this. A friend did one, rapidly realized t…
Re: Taking over a Dead IoT Company
#59Hello, author here. Happy to answer any questions! My apologies for the downtime, I wasn't expecting much traffic today since I submitted the post to HN yesterday but I've started scaling my server now!
Have any signs in the field connected to your new API and updated?
Re: Taking over a Dead IoT Company
#60Hello, author here. Happy to answer any questions! My apologies for the downtime, I wasn't expecting much traffic today since I submitted the post to HN yesterday but I've started scaling my server now!
I'll ask the same question as asked by @js2 below: Once the new server was up, did any signs from the field connect to it? Do you know how many signs are out there actively looking for the mothership?
> Good question! No signs connected to the server until I reached out to some other sign owners to try out my instructions.
I do not know how many signs are out there. I imagine most people would have just unplugged their sign after the company's API vanished since any data would be stale and useless.