Cord didn't win. What now? | Hacker News Reader

Cord didn't win. What now?

jg.gg

65 pointseamag59 comments

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

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.

I think it was open sourced after the fact, so probably the repo docs etc isn't super polished.

Correct. Though the docs do all exist in the repo. We opensourced it after we failed because our partners wanted to continue to use it, so we helped them migrate data and run their own instances of it.

The website is more helpful: https://web.archive.org/web/20240418130050/https://cord.com/

Think Figma comments as a service. Examples of it in production: https://www.workcanvas.com/

What are Figma comments and how are they different from regular comments?

They update in realtime, so it's kinda a mini chatroom linked to a particular element in your Figma design.

Like Google Docs comments?

Yep!

Yeah, the open-sourcing process seemed to have destroyed all documentation.

There are still 3-rd party sites with copy of the docs, like https://docs.comment.workcanvas.com/ (full of dead links), but it seems the main site used to be "cord.com" and this is already sold to some job search site.

I am surprised they did not open source the doc... or maybe no one has bothered to bring up the server?

They must have sold the domain to the job portal cord.co. I got an email about it in February:

> We're becoming cord.com

> Hi,

> Over the next few weeks cord.co is becoming cord.com. Adding an "m" to the end of our URL is one of the smaller things we've done. But it represents something much bigger: that cord has become the trusted source for tech hiring in the UK.

Yeah, the docs are open-source, but aren't running anywhere. https://github.com/getcord/cord/tree/main/docs/server/routes

Npm and docker are awesome for local development environments and I would say this has been done well.

Docker is used to setup the db, cache, and aws emulation.

https://github.com/getcord/cord/blob/main/ops/docker-compose...

Hmm... I've found both to be two of the tools I enjoy working with the least!

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

I find that an uncharitable take to assume lack of usefulness.

It’s more likely literally what the author says - getting engineers onboard for something they themselves didn’t choose is difficult. I’ve been in the same position - lots of buy in from leadership / solving a real problem and providing real value. Then it takes months to implement due to having to corral a dev team who simply doesn’t care about your integration.

Whereas i find that rather uncharitable towards the customers' engineers!

The tone here suggests deep misalignment of leadership and ICs. How can you end up enthusiastic about a direction at leadership level and have the ICs "not care," in a functional organization? That's a rhetorical question.

Same impression, after a skim of the Github. Looks like a net complexity add in most cases, if I understand its Readme correctly.

Due to the software culture I've been exposed to, especially in web-dev, I am cautious about any level of indirection added by third parties. They may seem like a value-add to first-order, but when managed in the context of a larger system, tend to make performance worse, debugging more difficult, and modifications high-inertia. Not as a principle, but based on observations.

For example, When I see text like this: > With pre-built components for chat, presence, and notifications, as well as fully customizable UI primitives, Cord enables rapid implementation of sophisticated, in-app collaboration tools.

my pattern-matching brain thinks This is probably going to be slow, require the user to download a large amount of data, and may or may not reduce code required to implement, and will make customization and modification tedius. Maybe this isn't true for this particular library, but it seems to be a good rule, currently.

Kind of typical in enterprise software. The software vendor puts all of their skill points into Charisma and sells the CxO level people on the product, sometimes to the detriment of the people lower on the totem pole who actually have to work with it.

Mgmt: It's got an API! It's got RBAC! It's Perfect!

Devs: It sucks ass.

Honestly, you're not miles off. Though with developers, it was actually more the "gotcha" variety of "It sucks ass".

We would have a senior dev on the dealing-making-or-breaking call and he would say something like, "Wait -- sorry, do you support <specific thing that our system doesn't have>?" We would say honestly that we don't have that yet. Then the senior dev would say, "Ooohh.... sorry... yeah... we need (per-message arbitrary data storage | support for on-prem | real-time analytics | per-messsage privacy controls | etc.)." We eventually had to face the reality that one of two things must be true:

1) The market is just too fragmented such that there cannot exist one product that serves it

2) The devs involved really, really don't want to give a product like this a chance because they actually want to build fun features like this themselves and they're (rightfully) skeptical that some random startup can do it better

As I sit here now, I have some confidence that it's 75% #2 and 25% #1. Anyway, the basic shape of the sales calls went a lot like what you're saying.

Most employees are unmotivated and mediocre-at-best, across every role and industry because most people are (rightly) just showing up to get paid. Engineers are no different, we are not special. Most engineers do not have the incentive to go out of their way to improve their product when keeping this as-is is easier for them. Regardless of whether the OPs product is good, almost all of the engineer opposition would come from engineers not wanting to deal with integrating some new thing that non-engineers want because it’s more work.

If you think most engineers are evaluating things based on the value it’ll drive for their product, you’ve lived a lucky career (and long may it continue).

An engineer's job is to add the features that management asks to be added. Engineers who fight with management decisions on adding features to a product are almost always exactly the ones who care a lot about the product - the path of last resistance is to just do what you're asked, since that's what you're paid for.

Management wants to add Google ads to their premium offline app? Sure, they'll work to add that, who cares. Whether they spend two months building this feature or another, they're getting paid the same amount.

> An engineer's job is to add the features that management asks to be added.

I get the context here (you are talking about software engineers, fine, and adding silly chat features, which is pretty low stakes). But, still, want to mention the general case:

The engineer’s professional obligation is to push back against the company if they are asked to design something impossible (and try to find some alternative that fits the customer’s business need if that’s possible), and to refuse or possible whistle-blow if asked to do something unethical/harmful to society.

We live in a very corporatized society where professions are being turned into jobs left and right. But, the engineer’s job is to just implement management’s requests in the same way that the doctor just exists as a conduit to your insurance company: that’s the way the company would like it.

An engineer's job is also to use their technical judgment and choose the right tool for the job. Some of the worst engineering jobs I've had were the ones where engineering is handed inadequate tools and told to use them.

That’s not how software engineering works. Management doesn’t know what a feature will cost to add so they defer to engineers who produce estimates which are used to forecast and plan. Engineers estimate based on their own preferences (whether for cynical self-serving reasons or not). You estimate a feature will be delivered in 2 months but it takes 4, that’s 4 months of pressure you could have avoided by rejecting the feature.

Some features are annoying to work on, some have long term implications for how much and what type of work will need to be done. Some just don’t fit with what the engineers want to work on. I know which features are going to take endless stakeholder meetings and which aren’t. I know which are going to require overtime and being on-call. I know which are going to kill off my pet project.

The most self-serving action a software engineer who doesn’t want to work more than the bare minimum can take is to reject as much as possible as being too difficult or bad or some other excuse.

I don't know in what type of environments you've worked, but "rejecting a feature" and "managers blindly deferring to engineering estimates" are very alien concepts to me, and I'm pretty sure to most people out there.

What usually happens in my experience is that management comes up with some new requirements that they may or may not have already sold to a customer on a more or less specific timeline. They then ask for an estimate on when that will be implemented in the product.

If the estimate doesn't conform to their expected timeline, they typically challenge it vehemently. If you can convince them that it's a realistic estimate for what they're asking, they then start discussing ways to reduce the scope while still delivering more or less the same feature. If you can't, then it will end up at "you're being pessimistic, let's start and we'll pull through", which will later turn into "we'll have to work this Saturday because we're way behind on what we committed on that feature".

Sometimes, a very well respected engineer will occasionally be able to convince someone in management that a feature is just not worth it. But that is the rarest case I've seen, and it will definitely not happen if some junior or middle engineer tries to invent some generic excuse.

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.

p.s. I said it wasn't easy, do I have any suggestions for selling to Enterprises where there may not be trust between the users of your product and their leadership?

Yes I do, here's one that is very well-suited to startups who want to sell to the enterprise: Product-Led Growth ("PLG"). This is defined as building a product and customer acquisition strategy around people trying the product for themselves and then buying the product without interacting with a human.

To make this work, you have to strategize which feature or features will close people using the product, as opposed to leaders looking at a PowerPoint with estimated ROI numbers. You have to make them discoverable, and you have to find a way to surface the value to users... In the product, not in a white paper or on a marketing web site.

You also have to have someone own PLG and ruthlessly experiment with user experience design and product design to drive better and better PLG. Yes, you have to track it and prioritize it.

PLG can't be your only strategy, you still need Enterprise Sales. For most enterprise products, PLG will never generate as much revenue as sales. It will be tempting to ditch it as wasteful compared to just building whatever the C-Suite demands from salespeople. BUT!

If you have any traction at all with PLG, your product will also be an easier enterprise sale. The problem the author listed is greatly mitigated by a product that has even modest success getting individuals and/or small businesses to buy it based on their trial experience only.

PLG can be the key to unlocking enterprise revenue, you just have to play the "long game" with PLG and treat it as a particularly honest way of obtaining user feedback, which must be coupled with a mechanism for improving the product based on that honest feedback: Someone must own PLG, must be held accountable for driving PLG, and they must have enough authority not to be swept aside by prioritizing top-down features.

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

The customer's in-house developers raised their hackles and had reservations about using the product, even though the customer's in-house solutions were terrible, because the customer's in-house developers wanted to build it themselves. I'm not sure if the article wasn't well worded and you misunderstood, or if it's me who doesn't see the irony.

The irony is that a valid reason for in-house developers to not want to use an external product is concern about the long term support availabilty for that external project. You could make a case that this product shutting down is proof the in-house developers were right not to trust it.

I don't think that's totally fair in this case, since it seems they open sourced their software. But also, in general, I think NIH syndrom gets a bad rap. Sometimes a "worse" solution you control really is more reasonable compared to a technically superior solution made by an external company.

Ive been doing this for 20 years and I have had to do several major migrations due to vendors doing all sorts of stupid things. Millions of dollars and so so many hours completely unproductive because a commercial off the shelf product was 'cheaper' to buy initially.

Feeling it :) Currently in day two of an outage with almost no vendor response for my entire platform because it was "the cheaper option" :)

Every quarter during budgeting I have politely pointed out this inferior service costs us a lot of money and sucks at support as well, and every time its considered not a priority.

Today its a priority :)

This exactly happened for the same product a few years - a real time push company called Pusher folder (or killed its major product) and everyone using it had to migrate.

Perhaps they didn't want to build it themselves and took into account the other risks like the company folding?

Or the cost being 10x'd after they come to depend on it.

That certainly hasn't ever happened to us before.

Every external { tool, vendor, SaaS, platform } is a potential risk. You don't want to eat a year of unplanned costs and a quarter or more of engineering hours of migrating off.

One of the reservations the customer likely had is "will this company be around in X years?" The inferior home-grown product will continue to be supported.

Thank you for clarifying for me so elegantly. That self fulfilling prophecy does have a sense irony to it, especially given that the code is open sourced.

So basically, now the developers could decide to use it for free if they wanted? Either they will, and they'll have saved their company a lot of money, or they won't, because the traditional issues they had with it are still there. I'm not sure how either of those ends up making the developers look like they made a bad decision.

It doesn't, and at least in this thread, I don't think anyone was saying it did.

Yes, the current state of the thread now that it's been too long for any of the comments to be edited further certainly doesn't look like anyone was saying it.

That's one point of view. Maybe from the other side the worst one wasn't the in-house solution.

Well, this is a very one-sided take. Imagine being a dev tasked with evaluating a product that makes you look redundant and also costs the company license fees in perpetuity. Whereas building a homegrown solution ensures that you keep your job, and get to look like a rockstar who saved the company money. Gee, I wonder which one the devs picked.

Why would adding an external chat solution to an app that is not about chat make the developers of the app look redundant?

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

Things like 'the cost of doing business' didn't make full sense to me until I was running a small one. I agree some lessons aren't easily taught unless you have skin in the game or some kind of first hand experience.

As a loose analogy paper trading can work great as practice(and if done right is supposed to help with this). Yet when u apply your system and stuff goes sideways, you're sweating and emotionally(as well as financially) impacted for real now, not just on paper. Those losses are real and paper trading would never 'hurt' like that.

I also like to emphasis the corollary for this: You can build so much more if you remove the “be profitable” constraint. Building a profitable business reduces both the problem and the solution space by a huge margin, and if you can find a way to get rid of that, the space opens up. As an extension, taking VC money reduces the problem space even further.

> Building a profitable business reduces both the problem and the solution space by a huge margin, and if you can find a way to get rid of that, the space opens up.

That's one way to look at it. Usually though, for upstarts, what's paramount is not the profits part, but the risks inherent in working on a solution for a perceived problem (or worse, for customers one is ill-placed to sell to [0]). I like what Seibel recommends: the v1 must solve an acute problem for the customer to pay up [1]. From there, building out a holistic product may put our upstart on path to growth & profitability while simultaneously expanding the scope of the problem space building such a product brings [2].

[0] https://www.michaelseibel.com/blog/users-you-don-t-want

[1] https://news.ycombinator.com/item?id=13109480

[2] https://apenwarr.ca/log/20211024

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?”

I think you're taking that far more seriously than it merits. I'd just read it as "we had fun times too"

> 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

Too right. I bet the 1.7K upvotes and 288K views were all shills and bots.

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.

Reply on news.ycombinator.com