Ask HN: What's all the fuss about product notifications? | Hacker News Reader

Ask HN: What's all the fuss about product notifications?

2 pointsdaveddev2 comments

I'm watching this segment called product notification infrastructure apis and there is a lot of activity and funding. Lot of products like Knock, novu, engagespot, courier, magicbell, supersend, fyno are in this space solving the problem and most of them are funded. Crazy thing is that the pricing is on the upper side!

Is product notification difficult for engineers? I don't really understand why someone could simply build it for a one time cost instead of "renting" it?

View on HN

Also these have been around a long time. Amazon has SNS for example. Those other services seem to do a little more, but as a user my take is that people want to send me about 10x the notifications I can receive.

I think there is a pretty big gap between what managers think is easy or hard and what developers think. That’s why there are so many ‘API integration’ products when coding against APIs is usually the easiest thing we do unless there is some complication such as complex authentication (e.g. A simple demo that takes 10 min to code up with any of 7 competitors takes 2 hours w/ Google Cloud and trashes your Python installation) or Microsoft’s SOAP.

I had worked on high-end search engines and that got me talking w/ about 20 ‘enterprise search’ vendors each of which offered 200+ integrations to get text out of everything from Salesforce to Mongodb. Only 1 however did systematic work to improve search quality. The thing is those ‘integrations’ are usually very easy to write for the run of the mill coder but the search quality work needs the attention of specialists that the vendor could justify but few customers could.

For a developer, it might look "easier" because literally anything could be built by coding if there is no limit on the time and money they can spend.

But for a company, this means more to them. Of course, they can build anything but there is something called "opportunity cost". A CPO or a CTO or the leadership thinks differently compared to a software developer. The decision is between "whether we should build this feature and add one more potential point of failure for or just buy it and let the vendor worry about it". And this time and effort (that could exponentially grow as the product scale) could be used to build another core product feature that will add direct value to our users.

Most of the time, the "buy" decision is less riskier and economical (in the long run), unless you are a tech giant like Amazon or Google where they might build everything in-house or just acquire the vendor's product and make it their own.

Reply on news.ycombinator.com