Ask HN: Projects You Thought Were Cool but Failed Miserably – What Happened? | Hacker News Reader

Ask HN: Projects You Thought Were Cool but Failed Miserably – What Happened?

41 pointsmscheong66 comments

Hey HN community,

I'm here to spark a discussion on a topic that, I believe, many of us have encountered but might not often talk about: projects that we were excited about and believed in, but that ended up failing miserably after release.

To kick things off, I want to share my own experience with a project called interfAIce. It's a Java/Kotlin library that allows developers to access Large Language Models (LLMs) by defining interfaces. The library automatically generates proxies that query the OpenAI API and formats the results into the defined return type data. I thought it was super cool at the time of development.

Despite my enthusiasm, my library never gained the attention I hoped for after its release. Reflecting on it, I believe the primary reason might be the mismatch between the technology stacks used by Java/Kotlin developers, who are mostly in server/mobile development, and AI developers, who predominantly use Python or C++. Of course, this could just be one of many reasons it didn't succeed.

This experience left me pondering, and I'm curious to hear from you all: What projects have you worked on that seemed promising or even groundbreaking during the development phase but didn't succeed in the market or with users for one reason or another? What was the project about, what made it seem promising initially, and ultimately, what led to its downfall?

More importantly, what do you think were the reasons for the failure? Was it a matter of timing, market fit, execution, or perhaps something else entirely? How did this experience influence your approach to future projects?

I believe that by sharing these stories and the reasons behind the failures, we can provide valuable insights and lessons for all of us, especially for those in the software engineering and development fields. It's a chance to reflect on the unpredictable nature of tech projects and the importance of resilience in our industry.

Looking forward to hearing your stories and learning from your experiences!

Google Wave is an interesting case study because they identified a real problem (email sucks), came up with some really cool open technology, but never quite put it together in the right way. The web client was slow and clunky, and they probably weren't focused on the right things.

A few years later, Slack comes along solving the same problem in a different way, and now platforms like that are the overwhelmingly popular choice for group communication.

Wave was ahead of its time and over-eager, but technology coming from it made its way into Google's other products for real-time collaboration at least.

Wave is the one that I think of the most because I first heard of it a couple of months before my company was about to release a product that did an extremely similar thing. We didn't want to go toe-to-toe with Google on anything, so immediately dropped the entire project.

Wave's failure meant that I'll forever regret that decision.

The way they released Wave was so bad that it should be a case study in marketing about what not to do if you want a product to succeed.

Their release approach was probably the key issue, besides the technical issues (primarily performance as I recall), that killed that project. I had access within a couple months of its release and had some number of invitations (single digit, 4 or 5?). I sent them all out, but the invitations were a lie. Invitations added your invitee to a pool of people who would one day, maybe, get an invitation if they won the lottery.

The result was that I was using a collaboration tool with no collaborators. By the time they announced they were killing it (about 15 months after launch, perhaps a year after I sent out my invitations), no one I invited had received access to the system. This crippled adoption for everyone who was interested in it, and reduced Google's interest in trying to salvage the system by dumping money into the engineering side (and Google already liked to kill products even by that point in their history).

and yet are still truly awful to use.

I thought ghost kitchens was a good idea: optimize for delivery, focus on foods that travel well, cut costs by using cheaper real estate in a smaller footprint and eliminating all the expenses that come along with people sitting in a space for hours. Probably less regulatory burden than a full service restaurant.

The reality was it just enabled a flood of crap onto the delivery apps.

Clustertruck (https://www.clustertruck.com/) is a regional entity somewhere between a restaurant and a ghost-kitchen. Delivery-only and a wide variety of meals, but they own their own app and don't list elsewhere. They check off the bullet points you mentioned.

The food is good but expensive, especially with delivery fees and tips. They've had to close a few locations over the years, so it's not a slam dunk in every city and I assume the margins are still slim.

Is it more expensive than DoorDash after all of the food markups, tips, and fees? Or at least comparable given the quality of the food?

I won't mention any particular failed projects, because the concrete examples aren't that important. The lesson that applied to all of them and which I think is relevant is this: I relied too much on their being a high-quality audience willing to participate, add quality content, and engage in the conversation.

The sad fact is that this doesn't really work: if the project will only work because you have high expectations of the general public, it will inevitably fail. Creating a community like HN that has a reasonably-high quality of participants is incredibly difficult.

Mozilla's Persona was a valiant attempt to save authentication from the Apple/Google/Facebook trifecta, but it failed because it wasn't easy enough to implement and there was chicken-and-the-egg adoption problem.

https://github.com/mozilla/persona

Something similar is still needed here, imho

I thought Google Wave was a rad idea. We’re still trying to solve the problem it was about—-collaborating digitally means using a bunch of different tools. That might just be life though.

We're sort of in this weird space where are still some phone calls and snail mail, texts, multiple chat apps, and email. They tend to be for somewhat different use cases but those are ill-defined and may be somewhat random even within a given organization.

Is it really a problem that needs solving? What’s the issue with having multiple means of communicating?

Fragmentation is something of an issue. I don't know if a given person at work mostly uses one of two chat applications or if they'll actually respond to an email. Personally, there's email but people I know use one of four different chat/text apps (five if you distinguish iMessage). Yes, notifications make some of that moot but there's a lot of fragmentation and I minimize my use of notifications in general.

(At work, it's partly that we've been migrating to Slack and you have people who basically only pay attention to slack and others who don't really use it.)

Losing track of information, and things not getting written down or forgotten about.

It gives a lot of power to The One App To Rule Them All though. And what happens when the company decides to switch to another system in 5-10 years?

Email at least has stood the test of time- Slack has not.

I still tend to favor email for a lot of things but understand that's increasingly a minority opinion especially for things that aren't routine updates, promotions, announcements, etc.

You don’t understand, we really need to be locked in a new walled garden

Man i have a whole grave yard of projects that failed, most of the time the problem is i can build it but i cant sell it :D so not even sure if it could sell if i knew how.

On the other hand i did gain some fulfilment while building my projects, sometimes learned something and sometimes even earned some money in a different way

I want to encourage you to frame this differently. Rather than seeing a pipeline where a product moves from a building to a selling phase, consider instead a process where you do a tiny bit of selling, then a tiny bit of building, in a loop where the goal is to build a thing so good that a little bit of selling kicks off out-control growth.

Yeah I don't regret the work that I put into my failed projects for the same reason :)

Here One earbuds, by the defunct Doppler Labs. Their precursor, Here Active Listening, didn't even stream audio -- they were focused on just augmenting your auditory environment. IMO way ahead of its time, they unfortunately came out before newer, more seamless wireless Bluetooth software stacks and lower energy chipsets that conserved precious battery life. Ultimately, a product with too niche of a demand to survive. Some of their innovations, like audio-passthrough, are common now.

The saddest thing to me is the really innovative stuff, the preset and customizable audio filters -- which would work even better now that earbuds have even more microphones and processing power than they used to -- have yet to be replicated on any newer hardware because no one seems to be interested.

Orkut and Reader. Both from Google. Orkut was just toy product for Google. But considering the fan base (especially from India) they got I was surprised they did not continue it. It was at the time overshadowed by Myspace and later Facebook. Google reader was a nice RSS feeder. Many people was disappointed when Google declared that they were shutting it down. For both these products, I guess main reason from Google was that they were concentrated on other things at the time. But most important I think these were not matching with there advertisement based Revenue model.

I built an optimizer for ship loadouts for a game I love playing, Highfleet. I also added ship file sharing, since that was really popular.

Nobody, even in that community, wants to use a tool to explore the trade space of highfleet ships - but I realized that was probably a niche case. And people are happy pasting their ship files into discord, getting 3 reactions, and never having anyone download them.

I think if discord had "download stats", nobody would use it to share things, given it is incredibly transient and impossible to search.

Disclaimer that makes the rest of the post make more sense: I do not have a college degree and did not have much of a formal education after about age 13 or so.

I thought I had stumbled upon a new and better way to do universal data compression. It was promising because I built a functional demo that beat (as measured by compression ratio) the native zip tool on Mac, Windows, and Linux, and even beat LZMA - all by a wide margin.

Fundamentally, the project failed because it was not actually able to universally compress data. The technical concept is most easily described as attempting to produce an algorithm that would offer close to the Kolmogorov complexity of the desired data, by rapidly changing the structure of the algorithm, the logical and mathmatical operators within the algorithm, and the initial values of the variables in the algorithm - i.e. attempting to brute-force something close to Kolmogorov complexity, which worked about as well as it sounds like it did: extremely well (better than alternatives) for already small, already extremely low-entropy files, and somewhere between "horribly" and "not at all" for everything else.

Trying to build it made me a more skilled developer, allowed me to learn more then I ever would've guessed I'd known about the Pigeonhole Pinciple, Kolmogorov complexity, information theory as an entire field, etc.

However, this one also made me a much better person. Bringing this project up to a colleague resulted in a book recommendation. That book helped to shine a spotlight on some subconscious racial views I formerly held that were unhealthy, but that I was unaware of, and being made aware of them allowed me to work past them.

100% urbit. The idea behind it (briefly: "personal server", an easy-to-use, no-frills place for an end-user to run server-side use cases like storing important files, hosting a blog, etc that's portable between cloud hosts and designed for long-term stability over performance) is a good one. Implementing it as a novel VM with built-in identity and crypto makes sense. It includes some genuinely hard/useful features, like exactly-once messaging between nodes. Kelvin versioning (counting down towards "done" rather than counting up as features are added) is a great idea for software that serves infrastructural purposes. Charging a one-time fee for cryptographic identities is an elegant way to make a de facto reputation network that disincentivizes malicious actors, and is also that rarest of beasts, a non-dumb reason to use a distributed ledger.

It had so much going for it, but it was DOA from launch for two reasons: first, the implementation is so bizarre that the kernel documentation is frequently mistaken for an elaborate joke, and second the founder's racist blog went viral at virtually the same time as the public launch. It's not technically failed I guess as it's still being developed and does work, but a network without a network effect can only go so far.

I honestly think the "personal server" idea would be incredibly useful, and it would also be very profitable (not the software itself, but for cloud providers) if every suburban family rented a $15/mo VPS. I post about it here from time to time in the hopes that someone will fork it or re-implement what is basically a great idea, but in a non-ridiculous way and without #cancelled taint of the founder. Bezos, if you're reading this, please put a small team on it just to see if it goes somewhere, I'll be your first customer.

This is the first time anyone's ever explained Urbit in an even vaguely comprehensible way. It always seemed like a ridiculous, grandiose exercise in ideology-first development to me, similar to the eye-scanner crypto orb.

"Oh, a distributed platform for small scale server apps," sounds like a valuable but not earth-shattering idea.

Like most platforms, it's valuable IFF a lot of people build on it. But the fact that I can make an on-topic, constructive and informative comment about it and still get downvoted tells you everything you need to know about how likely that is.

I think tech people often forget how important the human component is. Nobody wants to build their sandcastle in your sandbox if you're too weird or too much of an asshole.

Have you tried something like cloudron or yunohost?

Sorry if I was unclear, it's a hard thing to summarize, but the useful part of it is in being a platform for app development, not just the fact that it hosts stuff. "End user server-side apps" isn't really a thing that exists, because current server-side applications e.g. wordpress have to run on a variety of stacks, have to reinvent user authentication, etc. Another way to put it would be that urbit is a platform on which to run build server-side apps in the same sense that Android is a platform for client-side apps.

It does work tolerably well, people are building stuff on it, but I think it's too widely-hated to build a network effect. (Source: search for urbit on HN and click on literally any thread)

Google Stadia

Stadia's shutdown was a great loss in the gaming world.

Its social elements were ahead of their time, allowing for unprecedented levels of interaction and connectivity.

Other platforms are still catching up to how easy it was to jump into a game with friends, share game states, or even stream your gameplay with the press of a button; no queuing.

Unfortunately, much of Stadia's potential was undercut by Google's marketing strategy :(

The extra tragic thing is that if Google had committed up front to refund users in the event of shutdown - AKA the thing they actually did - they might have mitigated the fears that kept people off the platform in the first place.

Swatch Beat Time/Swatch Internet Time. I realize there are many good reasons why it never took off, but I found the utter rejection of the time zones and embrace of a decimal time system very compelling for both professional work and a work style that is divorced from sunrise and sunset (except when daylight savings drags us to and fro).

Colloquially, I don't see the 24-hour system going anywhere of course, but we long ago abandoned the concept that 12pm is actually solar noon with the advent of trains (at least, for the vast majority of people). Imagine not having to have to figure out the tz db just to log a time consistently referable from another perspective. What a beautiful fantasy!

Of course, it was still saddled with the Julian calendar, but that's probably going to take interplanetary commerce to see much benefit or traction.

I don't think anyone thinks noon is solar noon, but it is still "between morning and evening" for everyone.

I think of noon as the time of day when the sun is at the highest point it's going to get in the sky. Time zones are effectively a quantization error that means the clocks are usually wrong, but it's an error we all agree to so it works out practically.

But that fact doesn't change that noon is when the sun is at its highest point and our clocks necessarily include an error around when noon happens.

That's not a terribly useful utility in many contexts outside of social communication. As I said before, I don't see people using this for colloquial utility any time soon.

Hahaha, time is a social construct! Saying that our current system is not useful "outside of social communication" is like saying that food isn't useful "outside of sustenance". I mean, sure?, but that's the whole point of it.

> Hahaha, time is a social construct!

Funnily enough, it also exists outside the needs of society. I personally find the 24-hour time system—especially with its half-synchronized, half-solar construction—to be pretty miserable to work with for personal needs. It's also pretty miserable for many professional concerns as a social construct, even if you manage to agree on using UTC. Time zones are an absolute nightmare.

I thought Adobe Flex was damn cool. Guess Apple killed Flash killed this. I think there is an Apache version still around. React’s market share would make it irrelevant on the web though.

I had worked with it for a while (when I was at Adobe, a lifetime ago), and I thought it was a cool piece of technology. You could build up complex good-looking UIs fairly quickly. Was sad to see active development stop.

Ruby.

I still love the language, and maintain my SSG that was written in Ruby over a decade ago. Shame that it's nearly dead now.

I've got two: Transmeta and Foveon

https://en.m.wikipedia.org/wiki/Transmeta

https://en.m.wikipedia.org/wiki/Foveon

choir.io , I had hooked it up to our raw event stream so I could “feel by audio” how our systems were running.

Google Photo.

Such a shame that they closed this; even more shame that they didn't open-source this too.

What's Google Photo?

I know Google Photos, but that's still active, and haven't failed to my knowledge

There's still Flickr but I think the reality is that typical people have zero interest in a dedicated photo site.

Instagram is still a thing; granted it pivoted from being a dedicated photo site to a social network with videos and stuff, but still, it started off as a photo website.

Photographers were using Flickr a lot, but then Google started to randomly turn off websites and they realised they put all their eggs in one basket.

Yeah, I put Instagram in a different category from Flickr even though Instagram used to major in photos more and Flickr had more of a community aspect once upon a time.

I still have a Flickr subscription but I definitely recognize that it's a pretty small-time operation and it wouldn't be a shock if it were to go away someday. I like it but I don't depend on it.

Do you mean picasa?

I think that became Google Photos.

probably an outlier here, but at one point I thought that building optical brain computer interfaces made a lot of sense. It took about 6 years to figure out that it's a far far harder approach than high density electrophysiology, which hadn't been invented when we started the optical approach.

Firefox OS was my hope for phones.

It still sort of exists as https://en.wikipedia.org/wiki/KaiOS

It succeeded...just not with Mozilla at the helm.

There's also the currently-developed FOSS option https://capyloon.org/

Great question. I created a series of UI frameworks and experiments starting around 2018 that evolved like: "react in 500 lines of JavaScript", Brutal.js, Vanillaview, Bang.html, Good.html. The ultimate one was a realization of a long held dream unifying web components with the JS tagged template literals and easy "drop in" event listeners and "granular DOM updates without 'shadow DOM'" of my previous creations in that lineage.

The starting point was I disliked React's complexity and its violation of the implicit contract of the web platform in that HTML, JavaScript and CSS should function as the standard, if they're going to look like the thing. By creating a parallel but subtly different HTML/CS/JS DSL, to me it corrupted the platform and weakened it overall. I thought it a flawed approach and still do, and longed to see something better, so I built something that had the ergonomics I wanted.

I also really liked the things that came along like HTMX, Stimulus, Hotwire, htmz, etc. That I saw as giving power to the platform by using its technologies, along the "web grain": https://frankchimero.com/writing/the-webs-grain/

I hoped my frameworks would take on React, but I came to see there's more to tech than superior tech. It's about tribalism, too. Similar to beta vs VHS. Even tho React and Angular are inferior in many ways, the have the distribution mechanism, brand recognition, and "choice safety".

Ability to hit the ground running is oft-touted but I think it's less important than people think in front-end. Any really complex app ends up having to do its own weird stuff, that is non-intuitive respective the framework of choice, so hiring devs that "know React" is not super important as long as they know the front-end.

I think framework's are also about marketing. You can't just have superior tech, you need a pretty looking website, a catchy name, good design, too. But even if you have those things, it's no guarantee.

For me it would have been nice to have people adopt it -- tho perhaps it was not the kind of thing I would like to be maintainer of? I prefer products, like the successful ones I'm working on -- but the main thing was, and still is, that it is nice for me to use. It wasn't the only reason I created it, but it was the main reason: that I wanted a tool that I can use, and liked to use. And I created that, and still use it.

So it's successful like that, but not in terms of people using it who are not me! Tho, thanks to the popularity of some of the products (that we make) it's used in, it's install numbers get a boost because it's a dependency of those.

https://github.com/o0101/good.html

i miss perl

It funny... I find a radical division between programmers on this one. I was always a Perl-hater. I got into Unix/Linux in the 90s when Perl was big and I never learned it because I took one look at the syntax and some Perl code and my brain instantly recoiled in abject horror. I know lots of other devs who loved it. Still not sure what the division is, though I think it might be also related to the fact that I generally hate complexity and my reaction to it is "how can we get rid of this?"

I like to call it an acquired taste. First you hate it, then you fight it, then you get surprised, finally both you and Perl win.

Perl did not and has not failed. Not even remotely.

Perl is cool!

Elm

I felt like throwing together a quick frontend for a project at work. Downloaded Elm even though it hasn't been touched in years. Everything just worked.

These are the issues https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

Reply on news.ycombinator.com