Hacker News new | past | comments | ask | show | jobs | submit login
Bleeding-edge tech will kill your startup (contrast.app)
304 points by bmaho 34 days ago | hide | past | favorite | 191 comments



> As designers and engineers, we knew of a rather niche problem: if your company has a design system, it's practically impossible to know the adoption rate of those components in your product. Huzzah! we thought. We should build a tool that tells you the adoption rate of every component in your design system—across your product. Chefs kiss.

This article has nothing to do with bleeding-edge tech. It's about launching a product around which zero validation work has been done.

The quote above is the entire description of the alleged "bleeding-edge tech." I still don't know what the problem is. "Design system" is vague enough to me at least to be meaningless. There's a screenshot that looks like web analytics.

Web analytics have been done to death. This isn't bleeding-edge tech. It's me-too products desperately fighting for market share by going ever deeper. Big difference.

You've got to be an excellent communicator to play this game. Given the mismatched title and fluff in the article, I can see why the team had a hard time connecting with prospective customers.


The entirety of this article (and their startup's failure) can be summed up by this one line:

> prospects didn't know [...] the problem we were solving

If "prospects" don't know what problem you're solving, 99% of the time that means they don't have the problem your product solves. And if that's true, they're not actually a prospect. Seems like a classic case of being a solution looking for a problem.

Also the author's nonsensical "circle of death" reminds me of the "Conjoined Triangles of Success" from Silicon Valley[1]. Except Silicon Valley is a parody, and I don't think this article is meant to be.

[1] https://www.youtube.com/watch?v=cB7dInljmO4


I think the relevant phrase here is a "solution in search of a problem". I understand exactly what their product was intended to do and have worked on a lot of design system projects before, but adoption rate has never really been a key metric of anything.


A design system is a systematic approach to achieving consistent look-and-feel across the product(s) of a company.

This is in contrast to the "non-systematic" approach, which is to have designers use apps like Photoshop to copy-paste design elements and then have developers eye-ball and eye-drop that into code. You may up with lots of redundant definitions for essentially the same visual intent, especially with larger teams.

Most products start out with the non-systematic approach and then may later attempt a switch to a design system. Presumably, this is where this product could help you validate your progress. Whether integration of such a product is a valuable addition to your workflow or a distraction is up for debate.


It would certainly be useful, but I wouldn’t be very inclined to pay for it. It’s just not that useful.

You also need adoption across all the teams in your org to reap most of the benefits.


Design System is a term of art for UX Designers.

My wife is the UX Designer in the family, so I can't say more than that, though


Has any of commenters read the article? Looks like everyone talks about using bleeding edge tech in startup and how its bad, but this article is about building a bleeding edge product and how difficult is to sell such product (probably because everyone know that using bleeding edge products is dangerous :) )


Not even about bleeding edge products. It's a lengthy article about the pitfalls of entering a market with no market validation, which the author slapped lipstick on and gave this sexy title.


I had my first startup fail in the late 2000s because we built a sales prediction software that sounded cool, but nobody actually wanted. We even had a large paid pilot with a major auto manufacturer, but they didn't renew when it turned out that none of their employees had actually used the software.

Making something nobody wants is a classic startup mistake. I resolved not to make it again and read a great deal about market validation and building products.

I have one recommendation for those reading this thread: Steve Blank's "Four Steps to the Epiphany". It contrasts Product Development (focusing on a product with no customers) vs Customer Development (focusing on customer problems and building software around those). Honestly you don't even need the whole book, there's a PDF with the first couple chapters floating around [1]. I had a bunch of "holy shit, that's exactly what I did wrong" moments while reading it.

Eric Ries' "Lean Startup" is also an excellent book on this topic.

[1] http://web.stanford.edu/group/e145/cgi-bin/winter/drupal/upl...


Someone on HN once said “It’s hard to tell people the solution to a problem they don’t have”. Building software that solves a problem that the intended users don’t understand that they have is also a real problem.


Yeah, creating problems in people for which you conveniently sell solutions is the job of marketing.

As for building a solution to "a problem that the intended users don’t understand that they have", I'll agree that this may not be a good thing for a startup to do - but when I see how basic research is being defunded and drowned in red tape, and people saying that startups are the new, distributed R&D departments, I feel the middle has fallen out. When startups do a greedy gradient descent, and academia struggles doing science, who's going to work on solving problems that require solutions one or two steps beyond what the intended audience can understand? FLOSS community? What about outside software?


I should clarify that I see nothing wrong in solving a problem people don’t realize they have, and to be fair, this is what startups often do. However, many/most developers see marketing and sales as something unnecessary, eg. “How hard can it be”. And they realize that it’s pretty damn hard when it’s already too late.


April Dunford's "Obviously Awesome" is new(ish) and very good on this topic.


I agree. Look at the landing page [0].

First off, they hijack your scroll wheel and present you with some Apple-esque website that is very slow and doesn't work properly. > "Remote, component-driven, and obsessed with speed." I think not.

Second, they show zero screenshots of the service or what the benefits are to using it. > "Handoff reimagined." Yea, okay... Nice slogan, now show me before I move on!

No wonder they're having issues convincing new customers. They think they're selling a space ship when really they only need to improve their website copy.

[0] https://www.contrast.app/


Yeah, as someone who might use this product I feel like the landing page should be a long post on “how it works”. Frontend engineers are going to be very big stakeholders on this and I need to know, down to the bone bits how does it’s thing.


That was my take too - they built something nobody wanted, and it failed.


Exactly, its a classic we have a solution, but not a problem-to-solve let alone a product (yet).

“But guess what, they had no idea how to use our tool or integrate it within their workflow. And to be honest, nor did we. Adoption was bleak and feedback was dry—silence in startups is not golden.”


I read the article before coming to read the HN response to it. I haven't read beyond your top-of-the-thread comment.

The article resonated deeply with me, because I know just how the author feels. I, too, have developed a software product that attempts to address a key failing in one of the (more under-utilized) DOM elements we have at our disposal when building websites. I can see the problem, and some of the solutions - but other developers are simply not interested. I've marketed the product to the best of my abilities, written blog posts about why I think this is an important issue. I've even tried to engage with people supposedly interested in overcoming the failing to help me make the product even better ... <crickets-chirping> ... nothing.

The harsh truth is you can't market a solution to a problem that nobody else believes is a problem in the first place.

I've posted links to my product on a number of occasions to HN, both as 'Show HN' threads and in comments. Engagement has been minimal. My most upvoted comment on HN was a contribution to a thread about octopuses. Maybe HN is trying to tell me that I would be better off developing a standup comedy routine? Whatever. Unlike the author and his company, I'll not be pivoting away from my product in the near future: I just need to find new ways to shove its existence into people's faces.


I’m sensing some attitude issues just reading this, to be completely honest.

If your reaction to your library/product/whatever not taking off on HN is to get on HN and complain about it, you’re probably building whatever it is you’re building for the wrong reasons.

> I can see the problem, and some of the solutions - but other developers are simply not interested.

Developers are constantly marketed all kinds of solutions. You, the library author, have a responsibility to convince developers that the problem you’re working on is legitimate. If that’s not getting across, that’s on you.

> Maybe HN is trying to tell me that I would be better off developing a standup comedy routine?

Why would anyone want to take you or your work seriously after reading something like this?


Web accessibility is a legitimate issue that every front-end developer needs to care about.


It is a legitimate issue.

But it also doesn't cause the developer enough pain to register as a priority. The market is telling you something: it either isn't painful enough to spend money on, or you're not reaching the right people. IMO, you can sell to developers, but you have better luck selling them something that feels like it gives them a superpower, e.g. React is an easy sell because:

1. Reactive binding burns away a lot of imperative state-changing code

2. Facebook branding implies it is industrial-strength

And even then, React costs them their time to learn, build on, and ship. If it's their company's time, then they're not going to value it the same way.


For everything you think someone else needs to care about, there are probably a 1000 other things as well.

It's not necessarily if people care but what they care more.


You have solved the problem of the considerable "extra" effort that web accessibility requires? Less than that, to be honest I'm not interested. If you have, well, extraordinary claims require extraordinary proof. Would you say that you have extraordinary proof?

Reading this back to myself, I think that I sound like an asshole, but it's my honest thought process fwitw.


> You have solved the problem of the considerable "extra" effort that web accessibility requires?

Have I 'solved' web accessibility for the <canvas> element? No. Have I coded up a JS canvas library that has, as one of its central aims, the idea that <canvas> elements can, and should, be made accessible? Yes - that's what I'm attempting to do. It is a work-in-progress; I guarantee that my solutions can be improved on: Rome wasn't built in a day.

> Would you say that you have extraordinary proof?

The results of my efforts to date can be seen on the library's home page. Criticisms and suggestions on how to make things work better are always welcome! https://scrawl-v8.rikweb.org.uk/


It's true. The challenge is developing in a way that covers the wide range of human disabilities (e.g. vision to cognitive). WCAG will continue to evolve to try and capture the full range. That range of disabilities is why manual testing with a screen reader and a keyboard is the current best solution for uncovering edge cases where a website, or mobile app, is inaccessible.


> I, too, have developed a software product that attempts to address a key failing in one of the (more under-utilized) DOM elements we have at our disposal when building websites

Link?



Dealing with Canvas is painful. I recently ran into a weird image distortion issue on Samsung Internet Browser 12 (I guess it's based on the Chrome engine) when drawing a video frame to a canvas context using `drawImage`.

Since you've made Canvas your focus, I'm curious if you've seen this or have any ideas. Here are a couple reports I found online.

This one shows exactly what I see (note: this is not my post), and I was able to "fix" it using the technique in the question. I'm not particularly happy with that solution so I'm still working to understand what's going on.

https://stackoverflow.com/questions/63911732/javascript-canv...

Here's another report that seems related, although there's no mention of interaction with the video element.

https://forum.playcanvas.com/t/samsung-internet-browser-canv...


I don't have an answer for you, except to say that getting <video> and <canvas> elements to play nicely with each other across all browsers and devices is pretty much guaranteed to damage your day, week, or even your month.

My Google searching bought me to this posting about Samsung Internet's Video Assistant feature (Nov 2019). My gut feeling is that the Video Assistant is possibly getting in the way of your code executing as expected? https://www.xda-developers.com/samsung-internet-10-2-stable-...


One month is about right when you add it all up. Not fun.

Thanks for the suggestion. I have only found this to be an issues with version 12 and on. I have examples from version 9 & 11 that work as expected (both before and after video assistant was introduced). And I'm able to reproduce the issue with the video assistant turned off.

Of course, none of that is to say it's not related to the video assistant in some way. I just don't have evidence of that yet.


Haven't had a chance to look at the code yet, but how did you address responsiveness? It took us a long time when writing chart.js to get that working well on with different browsers, devices, and screens (high resolution screens require extra code)


First: chart.js[1] is an excellent library. If people need to add chart infographics to their website I strongly recommend they use a dedicated charting tool (like chart.js) rather than my library.

Like you, I've had to do a lot of coding and experimentation to get responsiveness working the way I think it should work. Much of it runs off the idea of drawing everything to a hidden canvas and then copying that canvas's contents over to the displayed canvas as the last step in the display cycle. I tried to mimic this functionality on the CSS object-fit property[2]. If you're interested in the code, you can find it here - https://scrawl-v8.rikweb.org.uk/docs/source/factory/cell.htm...

The other thing I've done is to introduce relative positioning for drawing stuff on the canvas. The native Canvas API drawing functions expects coordinates etc to be in absolute value pixels; my library allows coders to define positions and dimensions in String percentage values which will update (via dirty flags) each time a change in the canvas dimensions is detected.

Caveat: my library has not been tested (as far as I'm aware) across a wide variety of browsers and devices. I expect there will be plenty of improvements to be made once that happens.

[1] - https://github.com/chartjs/Chart.js

[2] - https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit


jQuery community has lots of different extensions. I searched 'jquery canvas' and this popped up: https://projects.calebevans.me/jcanvas/docs/text/

I'm not sure you have a 'product' you just have a library.


There are a number of excellent libraries ('products' - I use the terms interchangeably) dedicated to making development with the <canvas> element a lot easier; they all have a strong basic use case because coding scenes using the native Canvas API is very low-level, repetitive and easy to get wrong. Some of my favourites include Fabric.js, Konva and Pixi.js.


have you tried understanding how to find developers who has the problem in the first place? I think that you might get more traction that way.


Also the "bleeding edge product" in the article is some kind if analytics system that tells you the adoption rate of "components" (web widgets? Not sure) in your system. This might not exactly be what you think of when you hear bleeding edge, so take this article with a grain of salt.


Yeah, I read the piece and couldn't believe that this was the "bleeding edge" product they were referring to. At one point they call it "niche" themselves, which is a more accurate description.

"As designers and engineers, we knew of a rather niche problem: if your company has a design system, it's practically impossible to know the adoption rate of those components in your product."

Yeah, and I've never met anyone who cared to be honest. And if you do care, your answer is usually a quick "git grep" away.


That doesn’t really let you know how many components are custom and how many come from the design system.


It's actually hilarious. So many people enjoy sharing their opinion on the headline rather than the content of the article.


Sometimes people just want to talk about a certain topic, regardless of the article's contents. The headline just gives them a convenient excuse.


As 'CPLX says, for many of us the article itself is just a discussion prompt. Quite often (I'd say half of the time), the tangents and off-topics in the HN discussions are way more insightful and interesting than the submitted article.


Almost all of the time I submit something, that's exactly why: I want to read the HN comments, but there aren't any yet!


Which makes me wonder, why people insist on having a headline AND an article in 2020?

It only creates a confusion when most people don't bother reading articles when the headline is strong enough to inflict a response. It has become a tool to say something and deny saying it.


That got me thinking of an idea for a startup: let's build a service that allows people to broadcast headlines with no content (since no one reads the articles anyway), and then other people can reply to the headlines. To make sure that authors stick to the rules, we'll limit the length of each headline to 140 characters. Side benefit: users can post their headlines via a single SMS message.


Let's build a service that allows people to broadcast headlines with no content and then generate the content based on the comments or the responses.


I made a sketch of it on a napkin: https://imgur.com/UHLAdxQ


I thought I was so clever and was going to reply "you've invented Twitter!" and then I read the rest of your comment, and realized that was your point. Damn it.


In case it wasn't clear, this was tongue-in-cheek. This service exists, it's called Twitter.


The headline is there to make you want to click on it and view the article.

The article serves two purposes. It's primary job is to be a scaffolding for delivering advertisements to the reader. The secondary purpose is to be a word soup that makes the article appear in search results related to some popular topic.

That's it. Many people don't realize that the job of a headline is not to be truthful, accurate, or even sensible. It only has one job to do: make you click through, so that ads can be shown to you. Similarly, the job of a news article isn't to inform you about anything, but to keep you scrolling until the end, so that you may see more ads along the way. That's why you don't see the Inverted Pyramid anymore[0].

That's modern journalism in a nutshell.

--

[0] - https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)


Hacker News is a popular forum where participants engage in freewheeling conversations using headlines as a discussion prompt.


Thanks for this comment! I usually read the comments before the article and though it would be a Captain Obvious advicicle with snarky comments as are the comments here. So I wasn’t even considering reading it.

Glad someone took the time to read the damn article lol

Interesting reading by the way.


I actually started reading the article, which sparked my interest at start, but then faded away. so I thought: "This is going to be one of these articles where the comments are more interesting than the piece itself" and came here, just to find the excellent: "did any of the commentators even read the article?"


Is this actually someone just testing what % of people read the article before commenting?

It does make me wonder, given the deceptive nature of the title and obviously emotive topic of whether devs should use bleeding-edge tech...


OT but classic HN not to read the article and only comment on the headline. I feel this part of the guidelines makes it hard to address, when I really just want to say "RTFA before commenting" to some ridiculous comments that would make no sense if the poster had actually read the article.

> Please don't comment on whether someone read an article.

https://news.ycombinator.com/newsguidelines.html


Sometimes I read comments first before deciding to read article.


There'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 deliver on bleeding-edge technology. That's where your competitive advantage lies and that's where the nice margins are.

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).


>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.


Or pivot to "we're a blockchain-based database". And when that fails, "we're a blockchain stored in a database". After that, you'll have to get creative with the neologisms: "we're the first ever datachain backed by a Baseblock".


Hasn't the blockchain hype subsided a little by now?


Atleast in India its gone completely, Here they started with a blockchain( just a database stored on a central government servers) for everything. After crytpo currency got banned here and now i don't even hear blockchain anymore. People can't even differentiate between blockchain and Bitcoin lol.


Thankfully yes. I work in the space and we're starting to see projects/products roll out, without the high number of scams we saw in 2017/18. Hopefully by the next time the hype-train starts there's something there to be hyped about!


BITCONNNEEEEEEEECCCCCCTTTTTTTTT


Make your own pencil factory for the stationary cabinet too, as a backup plan. Buy a coffee plantation to fuel your devs caffeine habit, which can be monetised if the main biz goes south.


Or if you're a game studio, build a messaging platform to pivot to e.g. Slack and Discord.


> 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 deliver on bleeding-edge technology.

Also, if your business model does rely on new bleeding edge tech, avoid all other bleeding edge tech. Pick one thing that nobody else can do, and do that. Don't try and create everything at once unless you have ridiculously deep pockets.


There are these geniuses that can do something they never did before and create something truly amazing. But realistically even they don't manage to deliver on that the majority of the time.

Even the steam engine people had to rely on known standard parts like screws and bolts and known planing or manufacturing procedures that they didn't invent. Only because they knew which forces a bolt would withstand and learned from (at times catastrophic) failure they were able to even have a bleeding edge.


The standarized screw was after the steam engine. It wasn't until 1841 that Whitworth promulgated his thread. Before then every rail manufacturer had their own house standard.


It was standard to use unstandardised screws.


You are right, thanks for the hint.


Sometimes I need to echo things back to understand.

1. Start-up decides to scrap their current, unhappy business to pivot into a totally different area for which they have no long passion.

2. Start-up develops a product for a small, small niche: companies making design systems that also drive product development decisions based on actual, as opposed to requested, client usage. And said development company cannot use log analytics, roll their own, nor existing companies like Teleric.

3. They create a solution to said possible problem, without a planned first customer nor existing application.

4. They are surprised when sales is difficult.

I still don't understand.


Seems to be this article is about when your product is bleeding-edge tech, but people are commenting as if it were about building your product using bleeding-edge tech (in-house or otherwise).

Definitely only do one of these at a time, tho :)


Yeah, it's kind of like the classic "break one law at a time" rule. If you're hauling drugs, don't speed. Getting away with just the one thing is hard enough.

I think Discord is one good example of this sort of trade-off. Single, pretty standard type of app that improves on its predecessors, with some bleeding-edge engineering: https://blog.discord.com/why-discord-is-switching-from-go-to...

>Discord has never been afraid of embracing new technologies that look promising. For example, we were early adopters of Elixir, React, React Native, and Scylla. If a piece of technology is promising and gives us an advantage, we do not mind dealing with the inherent difficulties and instability of the bleeding edge. This is one of the ways we’ve quickly reached 250+ million users with less than 50 engineers.

>Embracing the new async features in Rust nightly is another example of our willingness to embrace new, promising technology. As an engineering team, we decided it was worth using nightly Rust and we committed to running on nightly until async was fully supported on stable. Together we dealt with any problems that arose and at this point Rust stable supports asynchronous Rust. The bet paid off.

(They also mention how they're careful to replace decoupled components incrementally, and only where it addresses a real need, rather than for the fun of it.)


What problem was Discord solving when they launched? Twitch already existed, Slack existed. Asking because it's a similar question I'm asking myself as I build https://sqwok.im, a news-focused public messaging app. I chose to use "bleeding edge tech", and have been challenged by peers about whether it would have been wiser to just use some off-the-shelf solution for parts of it vs architecting a fully custom a-z platform. I guess it depends. I don't see a site like Discord or Sqwok having a chance without a certain threshold of engineering to support the early product. That said, there's always the chance it doesn't matter because it's not solving a pain point for users. Sometimes it feels hard to answer without a tangible product to show.


* Skype sucked. Voice call audio quality was unreliable, managing lots of disparate groups sucked, if you had some random join your raid group (its initial market was FFXIV raiders as the initial team had previously worked on FFXIV utilities with guildwork) for the night you didn't really want to add them to your group chat for a voice call, it leaked information that was actively used to DoS people.

* It's users were consequently having to use multiple platforms, with teamspeak or vent or mumble for voice chat and Skype or Facebook for persistent text chat. This was inconvenient adding everyone twice.

* It's hard to explain how much it helped for the "bringing a random into your gaming group" scenario. You could just drop a link into the games text chat and people could join for the night and you didn't have to worry about if they had teamspeak or mumble or whatever installed.

* Teamspeak's free tier had a limit of like 10 users known to the server. Discord did not.

* Slack wasn't a competitor for Discord's initial market. Having to sign up for each instance was a deal-breaker. Discord originally allowed guest accounts, and I think it still does. Also the overhead to creating/managing a new server and adding people is really low comparatively.

* Discord doesn't really compete with Twitch much? People stream to their friends sure, and I have known people who had unlisted twitch channels for like jackbox in the past but that's a relatively late addition, and twitch is much more interested in the big streamers than the long tail anyway.

Obviously discord have significantly expanded their market a few times from FFXIV raiders to all mmo players to all gamers to everyone, but they started with clear problems to fix and fixed them well


Thanks for the solid recap, for some reason I forgot how voice chat was a big focus of Discord in the beginning. That might be because I mostly use Discord for non-gaming oss servers where voice chat isn't really a focus, and rather it's just a chat app.

It's interesting how they started out focused on gaming and have since moved away from it. I discovered a new Discord competitor, Guilded.gg, that sprouted up with marketing claiming Discord has abandoned gamers and they're going to recapture them.

It just goes to show that you never know which direction it's going to truly move and you have to be able to pivot. But having a core initial user group that you solve a problem for is key, and having a working product is key as well.


Discord was heavily marketed towards the gaming community that was split between Skype, Teamspeak, Mumble and maybe some others that I don't remember. All of them had some flaws while Discord just worked.


Excellent point and that makes sense.. I remember using Teamspeak way back in the day.


From my experience only, Discord was the successor to softwares like Teamspeak and Ventrillo for gamers, built as a social tech experiment. It also always had a FUN component to it, so it incentives creativity and people not taking stuff too serious. Children/teen seem to like it a lot.


> Yeah, it's kind of like the classic "break one law at a time" rule. If you're hauling drugs, don't speed. Getting away with just the one thing is hard enough.

I wonder if not speeding is enough to give police officers a reason to make a drugs search in some places.


Lol.

Czech here, I was stopped by the police once in the night on an empty 4-lane road doing exactly the speed limit. They breathalyzed me, looked at the zero and one of them said: "you know, when someone keeps the limit at midnight on this stretch of the road, they are usually drunk".


Next time a cop stops you for speeding, just explain, "I was speeding so you wouldn't be worried that I was drunk."


and you said: Why would I drink when I have 50 Kilos of coke in the trunk that would be stupid.


Yes, the article is exclusively about the trade-offs when building bleeding-edge products, like how impossibly hard it is to sell in to customers who have no idea what the product is or why it exists.

All of the comments for some reason are about not using latest-nosql-db-from-producthunt in prod.


I think the latter topic is generally more fun to commiserate about than the former. I have empathy for anyone that ernestly tries something ambitious and fails, and I'm glad the author found insight from the experience. Reading the article though, it sounds like the startup didn't really have a clear direction or momentum, tried to fix it by pivot ing to something technically "cool" without any business plan or realistic customer stories in mind, and then ultimately failed to create a sustainable business from that technology. A good lesson to learn from others rather than first hand, but not great subject matter to light heartedly banter about!


Agreed. We wrote about this and described it as having a well-balanced portfolio of technology. https://staysaasy.com/engineering/2020/05/30/Picking-Your-Te...


I have to disagree with the premise of the article. I've built a 'bleeding-edge' product for a very traditional market (public affairs) and succeeded. It's not because of the tech that a startup fails (unless the tech just doesn't work).

Yes, it's hard to sell something people don't understand, but that's marketing. So you figure out their needs and the needs that your product fills and you focus on that.

Pricing? You look at the cost of not using your product and go from there. Are you automating a human task that a single person does an hour a day? Start with that. Is your product reducing failures? Find out what those failures are costing. Start with that. Are you competing with a different product? Undercut or make sure your product adds more value.

Product? Get a couple of 'beta testers' and interact with them, often. Find out what they want for them to buy the product and focus on stuff you and other beta testers agree with.

Mental? Yeah, it is. running a startup isn't easy and nobody said it was. It took us over a year to proof that we could to what we wanted and nearly another to get to something we could sell. I got burnt out and ended up leaving.

Now, though, they started hiring and are getting more well-known in the PA community. Even PA firms are starting to lose customers to the tech I designed and built. It was never easy, it was very hard, but it wasn't because of the tech, it was because starting a business is bloody hard.


This reminded me of the early days of launching SnapScan. Firstly, it was about the 4th time we had rebuilt and relaunched a payments app. Then, we launched it for online payments which got absolutely zero traction.

Eventually we went and sat at weekend markets and coffee shops and spoke to customers and merchants one-by-one to explain to them everything about it: why we built it, who we were, how the security worked, where they could find us if we lost their money, how to download a mobile app, how to link a bank card to an app. We manually did this with probably over 1000 customers.

And then we gave them R50 to use it, and for the first year gave merchants the product for free.

This set us up for success. We deeply knew how customers perceived our app and using their phone to pay. We had also deeply educated a small army of people. And we had personal relationships with them, they had literally saved my number on their phone and could call me.

This article was a great reminder of the mental strain that took.


I don't think that is really true. Most start-ups fail, whether they build a bleeding edge product or try to compete on an existing market with smaller enhancements. After they fail if it's easy to pick the reason.

Very few start-ups succeed whatever they do. Skype was pretty bleeding edge at the time, the internet speeds wheren't really there at the time. Spotify or Tesla didn't enter a market with real competitors. Before they succeed, it's difficult to say whether they took the correct risk.

Someone has to be the first, chances are just not very good it will be your company.


Is that true with Spotify? Didn’t Pandora already exist and have considerable traction? rdio and a few others come to mind as well


I had never even heard of Pandora. A quick check seems to suggest that they are America-only, Alexa rank 800, while Spotify is international, rank about 80. As a European I hope I am excused.

Yes, Pandora seems to be older. How intense the competition was when it started I have no clue. I'd say it was bleeding edge in either case, in those days broadband internet was not so widespread, not to mention mobile data.


More than bleeding edge tech issues, which also exist, the article describes the classic solution-in-search-of-a-problem situation.


This isn't a new idea. And I think we already have better language in conventional wisdom to discuss it, i.e. New Market vs. Existing Market.

> Market Type changes how you evaluate customer needs, customer adoption rate, how the customer understands his needs and how you should position the product to the customer. Market Type also affects the market size as well as how you launch the product into the market. [0]

Incorrectly identifying market type can certainly kill your company, or make the process of working on it really painful.

However, I do think building a new market is a different kind of bet. Much more uncertain, much riskier, and larger upside potential (but I think that upside is harder to capture, especially if you're early in the space).

FWIW, I do like the pivot. We're using 1:1 component mapping between our designs in Figma and React front-end, it's something I can imagine using.

[0] https://steveblank.com/2009/09/10/customer-development-manif...


Lol. 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


I just went and checked, I switched our main product over from ARV Megas' to ARM Cortex in 2013. The only downside is that the ARM's don't have as good sleep current as AVR's do. And they don't have internal EEPROM.

Other than that they are faster, cheaper, and have more RAM.


Ah, I had the good fortune to at least run through Atmels with C compilers first ;-)

I definitely never expect to use a PIC or Atmel chip though, wow those were terrible. I guess small quantities really hurt.


PICs and assembly are honestly pretty great, if you know how to use them like that. I've never actually used C on a PIC because they are so resource constrained, but they certainly do have their uses.


That sounds like a huge jump! Now I'm curious what kind of solutions where PIC is viable isn't an overkill on Arm? (Or are there really tiny Arms?)


Low end cortex-m cores are pretty cheap these days. More modern designs and processes use silicon more efficiently, so you get more capability for the same raw material cost. Also, you can do a surprising amount with an 8-bit MCU. Lots of very capable 3D printers still run on AVR based controllers. Often times, you're limited by peripherals or memory size more than raw CPU speed.

As a baseline, it's relatively easy to make an autonomous aircraft that follows GPS waypoints using an atmega328 and have CPU cycles to spare, even using software floating point math everywhere. All the open source drone firmwares recently dropped support for orders of magnitude more powerful cortex-m3 flight controllers, though, and are encouraging folk to migrate to cortex-m7 based controllers. That's crazy! Software tends to expand to fill up any available volume over time...


Really... I wonder what the spare cycles are doing, whether it's truly waste and bad coding or if it's doing some kind of sophisticated predictive algorithms that we're unaware of. I do try to assume engineers did something smart, maybe there's a good reason...

I really hope the reason isn't "so we could run the mainline linux kernel" or "because we needed a RTOS" or something similarly bloated.


There is tons of human value in doing things good enough rather than perfect.

Why implement quicksort when bubble sort will give you the result you need just as "instantly" and be easier to verify?

Why bother procedurally iterating line by line through a 1GB of text in python, when you can call f.read().split("\n") inside a list comprehension and probably have it run just as fast because you have a 64-bit 4Ghz superscalered mmxzomg Inteliapple CPU and 32GB of RAM.

Often times, the bloat is an intentional tradeoff to make something else better. More accurate code, more readable code, more configurable code, etc. Other times, it really is just bloated, more terrible code; even that has some value, if it meant that someone was able to contribute a useful feature that they wouldn't have otherwise been able to due to lack of skill or domain specific knowledge.


Ah, I would have thought it was more like "feedback loop" going to "feedback loop with DSP" going to "feedback loop with DSP with wireless" or similar.

I think I am thinking more specifically about the flight feedback example compared to what you are describing, but I'm definitely all for using cheap powerful ARM chips in place of obsolete stuff. I'm just hoping that most of that spare computing power was used for something cool and not just spinning the wheels.


Often spare cycles can be used to sleep the cpu for longer cpu intervals and save power. Faster processors are often more efficient per watt, which can save a bit of power.


More advanced DSP takes more cycles. Eg moving from fixed low-pass filters to motor-rpm-following-notch filters gives lower phase delay, but requires getting telemetry from motors, running multiple harmonic notch filters on each channel. Supporting a wider range of protocols and peripherals takes more flash space. And eventually, when it gets complicated enough that you can't enforce deadlines everywhere, yes, you need an RTOS.


At least for drones, the move has been driven equally by flash space as compute. And the performance really has improved! Moving from fixed filters to rpm-following notch filters for example. Supporting wider range of peripherals and protocols. None of this comes for free.


Why wouldn't you use the more powerful chip if it's readily available, cheap, and efficient?

Much better to update the hardware when you have a chance than to stick with an obsolete part until the rug is pulled from under you and it's EOL'd.


I'm not disagreeing with you, but I don't think it's usually as simple as that for anything useful of non trivial complexity.

Most of the time, more power also brings more complexity. Cortex-M7 mcus, for example, typically can't reach their max CPU throughput without turning on instruction and data caches or "Tightly Coupled Memory". Data caching opens up a whole can of worms when interacting with memory mapped peripherals. Some MCUs with data caches have peripherals glued to them that are fundamentally incompatible with caching, leading to having to use indirect tricks like using DMA transfers to interact with them. TCM partitions your available memory space, leading to arbitrarily complex application specific linker scripts.

Newer chips are sometimes less capable on different axes. It's easier to use a 5V chip to interact with a 5V circuit, rather than a "better" MCU that is only 3.3v tolerant and requires a filtered 1.8V power rail for its internal circuitry. More complex CPUs generally have less predictable and potentially slower interrupt timing too.

Spinning new hardware also isn't cheap like spinning new software is, both in terms of dollars and in externalities. A popular community maintained firmware dropping support for an old but popular hardware generation that's become burdensome to maintain due to incremental feature bloat may be perfectly justified by the volunteer developers, but it does effectively turn that old hardware into e-waste. A company producing widgets with embedded components in it might want to defer the risk and schedule hit of switching to a new MCU architecture for as long as possible, in order to balance overall company goals and limited engineering resources. Justifying engineer months of work "because it's better and everyone will like working on it more!" is a lot tougher to prioritize than "because we only have enough stock left for 6 months and then we're scraping ebay".


PICs have extremely low latency interrupts compared to ARM, as well as the assembly language being really simple. 8-bit MCUs can be really great at some things where ARM isn't just overkill, it can almost be a problem.


Has nothing to do with bleeding edge. Problem is trivial to solve for anyone who actually needs to. It's not surprising a land grab to be an overcomplicated middleman service that is not needed and contributes zero value failed.

What is astonishing is that after the fact someone is still trying to extract value from it by positioning obvious learnings as insights.


I 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.


I tend to agree with this sentiment and it's what's driven me to build the mvp for https://sqwok.im. At least for this type of app/product, I don't believe a simple poc would be enough. I needed to get a working mvp into peoples hands to even have a shot of conveying the idea. Some people close to me have challenged me on this topic, which is healthy, but we will see how it plays out.


> We should build a tool that tells you the adoption rate of every component in your design system—across your product

How is that bleeding-edge? It's just "lint for design systems". What happened probably is that the number of people who actually use a "design system" is fairly small. And among them, those who understand what linting is are possibly rare...


It's interesting that the author indicates other companies like AirTable and Notion aren't doing anything completely new, merely expanding on existing ideas.

It seems to me that their product was essentially "usage metrics, but for component systems". Somewhat novel, sure, but I'd hardly call this _completely new_ as compared to aforementioned products.


" But guess what, they had no idea how to use our tool or integrate it within their workflow. And to be honest, nor did we. "

Uhmm, think I spotted their problem right there. If they (as the creators) couldn't figure out how it would fit in to a prospective customers' workflow then that is both an incredibly difficult proposition to sell and also an incredible waste of time for the customers that did decide to try it out. Appologies if someone has already stated that (read the article , skimmed the commments)


It doesn't have to be a waste of time. The thing is, you don't need to have all the answers if you just pick a potential customer and work with them. We had this exact same issue and we helped them integrate the product, while also learning about their processes, which helped us sell the product later. This is an investment however, it doesn't make you any money and that customer will probably be a net loss in the short term and you need to accept that.


This is the kind of thing someone might be offhandedly curious about, but no leadership is going to sign off on paying for a solution. At best some IC in the right position will add some instrumentation in the right place for a quick win. No one is going to architect their systems around something like this. The juice just isn’t worth the squeeze.

No shame in trying and failing at a cool idea, but I’m worried the author is taking the wrong lesson. It’s not about “bleeding edge” or being too early, it’s about target market and utility. No small company would ever need this, so you’re automatically moving into the enterprise space. However in the enterprise space you need to solve problems that decision-makers care about. That means going into sales mode day 1 and getting immediate feedback in order to land that first sale. You need a demo more than a product, and you need to listen more than you talk.


Could also be summarized as "pivoting hard is almost certain death" – bleeding-edge tech just changed the number of problems from large N to N+1. You have to basically shift the mindset of an entire company, and everybody was hired with pre-pivot skills in mind.


If OP is still not abandoning the project, they should add a Storybook addon as it does sound somewhat useful. My question would be how do we decide what adoption metrics we want. How do we identify places that a component could/should be used? The usage numbers alone don't seem incredibly useful, except to point out components that have low or no usage.

Regardless, "Bleeding-edge tech will kill your startup" is not a good title for the article. The actual article title (maybe it was updated) is a bit better- "Bleeding edge tech means you'll bleed to death". But most people here are miffed that neither title makes it obvious that the article is about selling bleeding edge tech.


Easier said than done I know (although I work in a technical capacity in a company that did exactly that - entered a market with tooling/tools that didn't exist, and had to prove the product actually had any value) - but I didn't see the part where they got trial customers, delivered on their value prop, and made them into case studies on how much value they were delivering.

If they were able to for example have a handful of customers who averaged (entirely theoretically) a 7% increase in profits at a cost of 1.5% of their operating profits, it would have been entirely possible for them to be on an upward trajectory.


Bleeding edge tech is not necessarily bad; not understanding demand, or communicating to your customer or having a market for your product is bad. This is ultimately what the post is about.


somewhat tangentially to the main point of the article:

> [this is your brain on drugs] "Firstly, makes no sense seeing everyone loves fried eggs. Secondly, this is how my brain looked when trying to start a "bleeding edge" tech company."

but... you undermine your own point! you just said everybody loves fried eggs, so shouldn't your brain looking like that with bleeding edge tech be a good thing? you just said it's a good thing.

I'm pointing it out because it's two of my pet peeves, (1) people attack the analogy, screaming "fallacy reeeee" when they disagree with the overarching point, then they embrace the analogy when they agree; it shouldn't be that way. The analogy is always a good thing, it's a metaphorical tool for conveying a point of understanding and it's not an argument in itself so it can't be a fallacy; and (2) people, young people especially, reflexively feel the need to endorse drug use and more broadly, decry any puritanical notion, to the extent of willing suspension of disbelief that porn, drugs, gambling, and addictions to dopamine might actually not be all that beneficial a use of your time. (I realize that's a complicated sentence; I'm trying to "weed out" the stoners)


One frequent exercise that I do with my colleagues who work with startups at ideation stage is to imagine how the value proposition could be challenged by a popular IM such as WhatsApp or WeChat.

We would ask ourselves: "Could process A be replaced by WhatsApp in this or that way?"

If the answer is Yes, then we would advise stakeholders to rethink that process or functionality to make it unchallengeable by the IM in the short run.


could you give an example?


> But guess what, they had no idea how to use our tool or integrate it within their workflow. And to be honest, nor did we.

They developed a tool without developing working out how it would be used. Is this a problem of bleeding tech in itself, or more of a problem of (product/service) comprehensive development methodology?


> As designers and engineers, we knew of a rather niche problem: if your company has a design system, it's practically impossible to know the adoption rate of those components in your product.

Why would having design consistency prevent you from understanding whether users are using a given feature?


Just want to say this website is what I think a modern website should look like!

Loads in under 1 second, has a simple but very cool design, no needlessly heavy JS framework in sight, due to the images it's a bit heavy at around 2.7MB, but still pretty good.


The blog part is fine, but the main page is janky as heck in Firefox.


Looking at their homepage it's very hard to understand what they actually provide.


On mobile it's impossible to understand what they do. Two words and then a screenshot that's impossible to read. Maybe that's why they've failed as a company. If you can't even make a reasonable homepage, what hope do you have in B2B sales.


My understanding: I want the components in my design system (e.g. Figma) to match the components in my front-end codebase (e.g. React) exactly, this tool helps me understand the current diff between the two.

From what I can see, the paradigm of component-based design has been growing in popularity since the tools like Figma have been improving rapidly.

In that case, it's a product for a niche and growing audience. I think the website hits some of the main points pretty well.


> My understanding: I want the components in my design system (e.g. Figma) to match the components in my front-end codebase (e.g. React) exactly, this tool helps me understand the current diff between the two.

This is what should be at the top of the the main page of their website if it's correct. Because endlessly scrolling hoping to find out what problem a product solves isn't a good way to sell a product.


Though the website's design is quite pretty, at least in my opinion


You always have to start with the underlying problem. The problems people have more or less remain the same. We can change the way we solve them, but you can’t ever make up the problem.


You 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.


It's such a difficult line to toe. Especially because people like working with new technology and it does seem to help with recruiting even if it makes actually operating the business harder.


Some people like working with new tech; in my experience most do it not because they like it but because of their resume. I like how I can get really good, cheap and experienced devs for ‘non hip’ tech because they do not want to work with new tech, they want to improve their skill on what they know; java/spring, c#/asp, django etc with jquery/bootstrap. Resume driven/recruiting forces them into all the new stuff but they rather take a pay-cut to work with the stuff they know and are good at. I need stability in software and my teams over the years; the continues race for the latest and greatest helps me do nothing for my business (making profit that is), including recruiting. Quite the opposite in fact.


> they want to improve their skill on what they know for me it's quite the opposite.., after around two years of working with some tech I feel like I can do anything with it and it becomes boring for me making me want to try something new.

but yeah my mindset always was being the jack of all trades, which is very good for small startups and not a good mindset for corporations which I avoid..


> I like how I can get really good, cheap and experienced devs for ‘non hip’ tech

> they rather take a pay-cut to work with the stuff they know and are good at.

The question is, are your employees aware of this?


Very much feel you there. Guess it's all about testing and trying to find the right balance


Why? I would advise finding better employees who respond to contributing to a solid business, and in return their own paychecks and bonuses.


Because working at a startup is a pretty big risk and people who enjoy taking risks tend to also enjoy working with unproven technology.


I'd think that one of the advantages of working at a startup compared to a more 'corporate' company is the increased autonomy. If you don't get more creativity over the solution, working in bigcorp surely has more advantages.

I also think the "sense of ownership" part that comes with making decisions like that is important. With a startup, it's beneficial if contributors feel they're able to fix problems they see proactively.

But, yes, I don't want to work with hype-driven or resume-driven coworkers. Yes, I want the choices to be pragmatic and well-considered.


There are still near infinite amount of good ideas outside of the mainstream that are new and exciting to most people, that are still well explored, have long histories and are mature.


So true! Such a difficult toe :)

Wondering how you have/are managing to do it?


too bad, it sounds like something that would have been useful at larger enterprises like banks and stuff. from the time i worked for one such business i know they were constantly obsessing over their 'house-style' meaning every product has to use the same components. I think they'd appreciate something like this. Of course i don't know how easy or hard it is to implement it. user friendlyness is key with such tools.


Will bleeding edge tech make you deliver faster?

For https://expose.sh I use TypeScript for the back end and the client so I get the benefit of one language for the whole service. TypeScript has been around for a few years but it is still pretty new compared to say Java.

By using Docker for the dev environment of the PHP ecommerce platform, it saved me from having to build one myself.


Brilliant article. We went through a similar phase in the startup we built. Can totally relate to it. :)


> So how did this mentality fuck us? Well, I've come up with a rather clever framework I'm calling:

oh god


The current global macro climate with 0% interest rates factors heavily into this observed outcome.


A 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.


TL;DR: "Make something people want" (source: YC homepage).


A product generates revenue when its market value exceed cost to produce.

If not,


We are still on RethinkDB but know we have to get off it eventually :(


We LOVE it... it’s been solid for the four years we’ve been on it. But we can’t stay on a dead product so we know we gotta make a migration plan


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.


This is a very interesting article because it is talking about two things and their conclusion seems to be wrong on both

*

A) They say they failed because they had a bleeding edge product

IN Reality: they are talking more about Product Market Fit not being there/not being properly tested

B) They say that selling such a product is difficult, getting companies to implement it is difficult, and that the mental game is more difficult

In Reality: They seem to not fully understand their own product, what their customers' needs are, and how their product matches those needs

A few other points, with some overlap with the above

Firstly, that product they discuss is not very bleeding edge. It's basically Analytics. It's not like they were trying to sell Virtualization or Nuclear Fusion Reactors

It's Analytics/What Gets Measured Gets Managed/Pareto Principle

-> We should build a tool that tells you the adoption rate of every component in your design system—across your product

How is that bleeding edge?

*

Secondly, Winter 2018 to Summer 2020

That's 1.5 years

Is that really time to tell if a product is a hit or not?

Look at all the companies that are going IPO now. They are between 5 to 20 years of existence before IPO

Outliers like Amazon and Facebook have really messed up lots of people's perceptions of what building a company should be like

They think everything is going to come together in one or two years

Thirdly, all their problems (sales is hard; companies adopting product is hard; mental game is hard) is basically

A) Your product doesn't have Product Market Fit. If there is a good fit then NEW makes it sell faster because no one else has it

B) Your mental game is weak. If you are going to give time to a product (even a not that significant 1.5 years of your life) you must make sure you give it your best shot

C) It seems all your issues rise from you thinking SOMEONE ELSE is going to do stuff for you

You have to sell

You have to get the company to adopt the product

You have to keep yourself focused and positive

*

Do you really understand what problem that product solves?

Does your customer want that problem solved?


another excellent article on the same topic https://mcfunley.com/choose-boring-technology


No, it's not the same topic. I know we're not supposed to ask if people read the article, but you are commenting based on the headline here.


This.

People will buy what they understand.

Who can blame them? Your real bleeding edge tech company is outnumbered by snake oil companies 1:1000.


That's bull. People bought the iPhone in spite of 'it has no physical keyboard', 'it has no copy paste', 'there's no place to put a stylus', et cetera. If people don't understand the product, you need to sell it in a way that they do understand. That's why marketing is still an expertise and not a side gig in most successful companies.


The iPhone wasn't successful because it was "bleeding-edge tech", it was successful because it was a bold and innovative remix of existing technology.


But 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.


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.


Good at smaller scale, and Heroku can go pretty good at scale. But eventually you run into things that they make harder rather than easier if you need to do something which doesn't fit well with their model. Deploying onto Google Kubernetes Engine has a bit of boilerplate setup work, but after that it's not a huge management overhead considering everything it gives you.


Okay, yeah, for sure. I think they're better options for early iteration. I guess actions speak louder than words here since my preferred operational stack is Rails + Typescript + React + Redux + Heroku w/ Heroku Postgres.

Yeah, definitely Heroku over k8s for idea validation.

I think there's definitely room in the k8s-based space for slightly past that, though.


Outdated stuff.

I use the Jojoma framework to abstract away all that Kube stuff. It's trivial to use through Baobab, especially if you use the Wazabi framework-as-a-service framework (which you should). All you have is to deploy the proclets through a DMVC and it's all automagic.

I iterate through 17 startup ideas a day using that setup.


I genuinely thought for a second you were describing something new that I'd missed the boat on. Hahaha!


Still using the JBWD stack huh.


Lol - true true!


Had a $4 mouse from the dollar store. Watched some youtube videos, and decided to splurge and bought the latest and greatest bleeding-edge Mx master 3, at $129 and 3225% more expensive. Despite all the great reviews and hype. I'm kind of hating it. Damn thing is so heavy.

It feels like I'm moving a brick around. Was going to return it, but now I'm saving it for a protest.


>>It feels like I'm moving a brick around. Was going to return it, but now I'm saving it for a protest.

I thought it was still bumble bee tuna.


The weight is something I love about MX Masters.


I love the weight too. However, the battery life sucked -- last time I had one, kept dying after a week needing a recharge. I then bought a Logitech Marathon mouse and I'm already going 2+ years wireless on a single set of AA batteries. That makes me happy. I like products I don't have to think about charging all the time.

I wish they covered the mice in solar panels like the solar-powered wireless keyboard, or harvested kinetic energy though -- that keyboard is another great Logitech hit if your workspace is near a window -- you never have to charge it.


If you didn't buy that used, you probably should've complained to logitech. My master 2 runs ~1 month on a single charge, and when I see the third light blinking I usually just plug it into my laptop overnight. I've not had to deal with a dead battery in this mouse, ever.


Yeah it was new. Weird. Did you have to install any drivers to get it to power save efficiently? Because I run Linux and don't have any Logitech proprietary drivers installed.


Nope, and I use linux too. If you do want a driver for linux, logiops is great: https://github.com/PixlOne/logiops


I know I'm comparing apples to oranges, but I own a Logitech MX Anywhere 2S and the battery seems to last forever, even with constant use. It works on any surface, too! The best mouse I've ever used.


Best mouse I've found is the Logitech G Pro, it annoys me that it's full of stupid RGB lights, but it has the precision and speed of a good gaming mouse without being too ridiculous in design or cost ~$60


That Logitech mouse shape is basically perfect. I've been using mice with that body profile for 15 years now. I periodically check up on the newest iterations to have my replacement bookmarked, but this decade old one seems content to keep chugging on.


I use a Logitech G502 and it's great. This is the second one I've had (spilled drink on the first one, RIP) and I'll buy the same again when this one dies if they're still around.


Also only had random $5-$10 microsoft basic mice since like the early 2000s, changed to gaming mice and didn't like any of them, and my last trial the mouse broke after a few weeks (logitech g pro).


I have $300+ in Apple mouse and trackpads connected to my computer but I still find myself using the $30 dell mouse that I got as a backup.


I love my Mx master


It is a great fucking mouse, but it's not for everybody.


Cans of tuna are cheaper and tastier.


As a Vegan, I'm repulsed at throwing dead fish at people. Also they kill dolphins when they catch them. Dolphins are "people kind" best friend in the ocean.


How about vegetable soup?

Furthermore, there’s plenty of dolphin safe tuna out there, which does mean something as designations go:

http://savedolphins.eii.org/news/entry/what-does-dolphin-saf...


Its more ethical, for sure, but only if it's vegan soup.


Plus, fishing is really unsustainable: fish depletion, severe harm to non-edible species, high energy usage, carbon emission, geopolitical tension.

Finally, it's one of the most dangerous jobs, and often exploitative.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: