Cord didn't win. What now?
I am the only person who browses https://github.com/getcord/cord and just doesn't get what it does?
Like, it's not clear to me what problem it solves.
It's described as "The complete SDK for Chat, Commenting, and Notifications" yet I've read the entire readme and it isn't clear which languages it has client-SDKs for, if any.
If my boss came to me and said, "Can you evaluate Cord for a chat and notification back-end" I'd return a quick message ruling it out on the basis of there being no documentation, no example integrations, no obvious client SDK packages, etc.
It's also hardly zero-friction just getting it running. It needs both Node/NPM and docker.
Why? Either ship me the NPM packages, or point me to a docker command I can run. If it's containerised, why does it need NPM? If it's shipped as NPM/source, why does it insist I deploy with docker?
Show me some simple code examples so I can see how easy it is to get a chat client running, don't give "broken" links to docs and APIs that would only work if I'm already running your software, I'm unlikely to get that far without browsing the API and docs.
> We were constantly faced with product leaders (VPs of Product, CPOs, PMs, etc.) who were very excited about adding Cord to their existing product. They saw the value unambiguously. And then we’d get to the dev team and face a stonewall of NIH syndrome alongside a clear preference for building it all themselves, even when that meant shipping a vastly less-useful product to their end users.
From the other side, this looks like "management signed up for some flashy product based on marketing, but it turned out to be useless". Not recognising that seems like a substantial blind spot.
It would be interesting to hear from anyone who evaluated Cord and decided not to use it. I wonder if the risk that the company might fold entered into the decision.
Still, excellent of them to have open-sourced it; it superficially looks like they've put a lot of effort into making it usable.
Before I went into development full-time, I was in Enterprise Sales.
There were times I sold a product that the users (Dev Team in the author's case) wanted desperately, but leadership (VPs of Product, CPOs, PMs in the author's case) didn't see the importance and/or urgency of. And yes, there were times when I sold a product that leadership wanted desperately, but users didn't see the importance and/or urgency of.
The second case can be wrangled over user objections, but in the long run, such products end up failing once past harvesting the Hawthorne Effect. The lasting successes were the ones where all the stakeholders (I know, I know, buzzword alert) bought in.
And that's why closing Enterprise Sales is a load-bearing role in an Enterprise Software business. It's hard to do, but through a combination of product design that creates discoverable value for every "buying influencer" (another term of art from sales) and needs discovery on the part of sales and product management, followed by tailoring pitches and demonstrations for each group, you can get them all in a room nodding together and close the deal.
It is NOT easy. And a lot of this is not the vendor's fault. Beneath the superficial appearance of a recalcitrant dev team, there may be scars from previous top-down dictated changes that did not, in fact, do anything for the users or the company, so closing a deal may involve a lot of listening and empathy and a very open mind.
People make fun of Enterprise Sales as a perfectly coiffed salesman golfing with the customer's CIO, but the hard truth is that Enterprise Sales is hard because Enterprises are full of people with complicated needs and relationships and perception and the entire thing is steeped in hidden historical legacy context.
I feel for the author, I really do. But I also reflexively feel for the customer's dev team. And for the customer's leadership. A change to communications tooling is a change to a load-bearing part of a company's processes and culture.
Selling this kind of thing is not easy.
I don't know anything about Cord beyond this article, but my team has worked on many projects over the years where we had to add chat / commenting / notifications functionality.
I can see this being a tough market.
One - it's a crowded field, with many solutions in each of those three categories. I don't think we've actually come across Cord while evaluating solutions, which just shows how noisy it is.
Two - I struggle seeing "chat / commenting / notifications" as a unified category. Every project we've worked on had unique requirements for each of these (whether justified or not...) so every implementation ended up being different.
It's definitely a pain to roll out these features from scratch, and we always preferred using something off-the-shelf where possible.
But by the time you finish evaluating options, pick one, implement and customize it, deal with its limitations and bugs - plus projecting several years of usage costs, and uncertainty dealing with an outside vendor - I can easily see how the balance might tip to doing it in-house in many cases.
Not trying to armchair quarterback - I know how hard startups are, and respect to the Cord team for being in the trenches! Just sharing my experience.
The in house developers raised their hackles and had reservations about using the product even in the face of perceived inferior solutions. The product then goes out of business... The irony of this story...
This is a lesson that a ton of developers / engineers can learn, and it's hard to truly learn it via any other way but The Hard Way and I definitely sympathize with OP; making a great product isn't always the same as making a profitable product and a great business. Once you get to "selling something on the Internet", it gets a lot harder and the rubber hits the road, so to say. Thanks for the insightful write-up
> We were constantly faced with product leaders (VPs of Product, CPOs, PMs, etc.) who were very excited about adding Cord to their existing product. They saw the value unambiguously. And then we’d get to the dev team and face a stonewall of NIH syndrome alongside a clear preference for building it all themselves, even when that meant shipping a vastly less-useful product to their end users.
You are painting the adoption problem as the software team having a different opinion on the build-or-buy decision. It could be they were OK with "buy" but didn't like your product for other reasons.
You've said that management teams liked the idea of your product, not that engineering teams liked working with your product. All software these days is built on stacks of OTS software. Of all the external dependencies they took on, why was yours different?
I've been on a bit of a tear recently, throwing away internal tech from 5-15 years ago that was inventive at the time, but where high quality off the shelf solutions now exist. I've still skipped on number of things I've wanted to pull into our stack. But they're too opinionated when they should be stupid libraries or flexible external services. I can't reshape our existing software to fit their idea of how our product can make life easier for them.
> We memed so damn hard.
I still don’t get this obsession that startup founders have with “memes”. Like I get it, everyone loves internet jokes, but when I hear CEOs use the verb form and talk about it like it’s a core strategic practice (this seems to be commonplace among founders who like Elon) it has a strong ring of “How do you do fellow kids?”
> great tech isn’t enough ... You have to solve problems they can’t and/or don’t want to solve
Great insight.
I clicked all 4 of the linked memes and they were so painfully unfunny that I now intrinsically doubt the author's ability to understand any audience.
Look at the comments under the first one, lol
https://www.reddit.com/r/ProgrammerHumor/comments/14xljje/yo...
> import thefuckisthis
> printf("this meme format is garbage, please promote your site in some other manner");
> return downvote
This may be due to my limited perspective, but I just don’t see that big of a market for a product like this. (Not that I’m all that clear on what it really does either.)
I was confused because the only "Cord" I know of was the jobs site.
My company, https://talkjs.com, is in the same market as Cord was. We let you put a full-featured chat UI inside your app; you control all the details and we handle the realtime infrastructure and scaling up.
At the time we were rather surprised when suddenly, seemingly out of nowhere, Cord popped up as a direct competitor to our product. We were even more surprised to find out that, only a few days after we learned about them, they had discontinued.
I just gotta say that not everything the author shares resonates with me. Notably the idea that devs really really want to code chat and commenting from scratch. Our customers generally have plenty of competent developers on staff, and these devs all have plenty to do and generally they just don't want to waste time building an entire WhatsApp clone inside their platform/marketplace/tool/whatever. They'd rather spend that time working on unique features for their market instead.
We do, however, need to convince developers that they can control everything they want to control. If they get only the the slightest idea that we're either bullshitting them or simply not letting them build what they want to build, the conversation is over right away. I suppose this holds for any product that sells to devs though (or one that sells to PMs but is, in practice, vetoed by devs).