More than bleeding edge tech issues, which also exist, the article describes the classic solution-in-search-of-a-problem situation.
Bleeding-edge tech will kill your startup
11–20 of 196 posts
Re: Bleeding-edge tech will kill your startup
#12But we have to use kubernetes. Jk. But yea, especially if your startup is not really high-tech, but merely a good business that needs tech.
Kube is great. Abstracts away lots of problems. If you make a single kube cluster (which is trivial with eksctl) you can iterate on a number of startup ideas pretty quickly on it.
The kube API (the pod/deployment/service/ingress structure) is where the magic is, imho. Sure you could just make an EC2 instance, and swap in your Rails, and redirect the ALB and fix your domain CNAME, but whatever man, you can do like 4 of those things in an instant in Kube.
Re: Bleeding-edge tech will kill your startup
#13I disagree. There is always a space for something bleeding edge. Your fatal flaw was not creating something "new" but the fact that you didn't actually build the product. A product that has no easy ability to integrate with a workflow is not a product, it's a proof of concept.
Re: Bleeding-edge tech will kill your startup
#14A lot of the problems stem from just constantly changing the tech.
I used to work for an organization that has a team of mostly Java developers. They want to move to Python, in part because the big guys (Google, Netflix, and NASA as cited by them) did it too.
They are just building a run of the mill web app, but they are changing the entire stack for a new project that next to nobody on the team knows well.
Re: Bleeding-edge tech will kill your startup
#15We are still on RethinkDB but know we have to get off it eventually :(
Oh wow I worked on a project over 5 years ago that insisted on RethinkDB. Man so many issues... Lol
Me too - not least the rushed port job I was forced to do from MySQL to RethinkDB (which resulted in predictably shitty code)
FWIW I actually really quite liked RethinkDB.
Re: Bleeding-edge tech will kill your startup
#16You have to toe the line a bit in startups, you want to use proven technology but leave room for the employees to feel like they are contributing to something new and unique.
Why? I would advise finding better employees who respond to contributing to a solid business, and in return their own paychecks and bonuses.
Re: Bleeding-edge tech will kill your startup
#17Lol. I'm an embedded engineer, and this week I'm getting my coworkers excited to upgrade part of our system to use bleeding edge technology from the mid 90's!
Re: Bleeding-edge tech will kill your startup
#18There's a distinction to be made: - If your business doesn't rely on new technology, then avoid bleeding edge tech (examples: you retail co-working space, rent apartments, do food/grocery delivery, etc.) - If your business model does rely on new technology (examples: airlines in the early 20th century, railroads in the early days of the steam engine, e-commerce in the early 2000s) then you have to work out a way to d…
>Though even in the latter scenario, it's still prudent to narrow the scope of your bleeding-edge tech as much as possible (e.g. if you're doing a cryptocurrency app, you probably shouldn't be trying to make your own NoSQL database at the same time).
Nonsense, the database is the back up plan so you can pivot to a DB company if your main thing doesn't work out.
Re: Bleeding-edge tech will kill your startup
#19Lol. I'm an embedded engineer, and this week I'm getting my coworkers excited to upgrade part of our system to use bleeding edge technology from the mid 90's!
Just getting hardware upgraded from very early 2000s PICs to ARM chips has been a pretty big win for me
Re: Bleeding-edge tech will kill your startup
#20But we have to use kubernetes. Jk. But yea, especially if your startup is not really high-tech, but merely a good business that needs tech.
Kube is great. Abstracts away lots of problems. If you make a single kube cluster (which is trivial with eksctl) you can iterate on a number of startup ideas pretty quickly on it. The kube API (the pod/deployment/service/ingress structure) is where the magic is, imho. Sure you could just make an EC2 instance, and swap in your Rails, and redirect the ALB and fix your domain CNAME, but whatever man, you can do like 4 o…
You know what abstracts away all those problems but doesn't require hours a day of mucking with scripts? Google App Engine. Heroku. Elastic Beanstalk.