←back to thread

80 points pz | 4 comments | | HN request time: 0.965s | source

Hi HN, I’m Phil, one of the co-founders building emdash. Previously, I was an early engineer at Facebook and led Customer Products at Square.

We’ve focused on making chat and video work together so distributed teams can stay aligned without drowning in information. You can try it here: https://emdash.io.

It frustrated us how easily important conversations would happen and then disappear. Slack never quite matched how we worked. Channels were too coarse which led to noisy notifications and broken search. Zoom meetings weren’t much better–unless someone took perfect notes (which rarely happened), video calls became black holes of lost knowledge.

We spent too much time trying to find the information we needed to do our jobs.

To address this, we’re testing a few concepts and would appreciate your feedback on the value of the following:

(1) Automatically record, summarize, and transcribe your team’s video chats. We store meeting content directly inside discussions to facilitate search and discovery.

(2) Make it easy to manage & organize conversations of varying scope. A chat between team members can be forked into a dedicated Discussion with its own audience permissions and subscription. Individual messages or entire Discussions can be moved after the fact. Conversations can evolve unpredictably, so having the right tools to keep them organized post-hoc was important to us.

(3) Improve search with AI and hierarchical information retrieval. We use LLMs to uncover insights, summarize content, and connect the dots across related discussions, meetings, and documents. You can ask questions like “What are the team’s priorities this week?” or “What did we decide to do with feature X?” and get back a generative response AND deep links into the original chats and meetings.

Try it out: https://emdash.io and tell us what you think!

Show context
mtlsnk ◴[] No.43191826[source]
This looks great. What is the reason for adding the https://sso.tax? Why did you make SSO an enterprise feature?

Is it due to some (technical) reason that would require a monetary compensation to be profitable?

SSO has security benefits (on top of the maintainability aspect) which would also benefit small businesses.

replies(3): >>43192067 #>>43192144 #>>43195961 #
IshKebab ◴[] No.43192144[source]
SSO tax seems like a very reasonable price differentiation method to me. Most of the price increases on sso.tax are quite reasonable for a company that needs SSO (most companies I've worked in don't bother until they are above 100 employees, despite what that site says).
replies(3): >>43192282 #>>43192315 #>>43196064 #
anilgulecha ◴[] No.43192282[source]
> SSO tax seems like a very reasonable price differentiation method to me

Security is not a differentiation method. It's table stakes for any technical product. That's what the above linked website explains.

replies(1): >>43195978 #
lelanthran ◴[] No.43195978[source]
> Security is not a differentiation method. It's table stakes for any technical product.

Security as table stakes, sure. SSO, certainly not.

It's an additional cost, last I checked it was between 10$ and 20$ per user per month if you take the cheapest option and outsource it.

This whole notion of "Unless you meet this security standard that 99% of products don't meet, your product hasn't met table stakes" is nonsense and needs to die.

SSO will get cheaper in the future; for now it's hard for a product development team to justify getting 0$ in revenue just because of some purity test by irrelevant folk on the internet.

replies(2): >>43197157 #>>43201592 #
1. rad_gruchalski ◴[] No.43197157[source]
Running my own keycloak or another ory hydra is a boring task. Locking SSO behind some arbitrary scale and raked up price takes sales away from you. It’s a matter of perspective.
replies(1): >>43203156 #
2. lelanthran ◴[] No.43203156[source]
> Running my own keycloak or another ory hydra is a boring task.

Simply running keycloak is not sufficient for SSO.

An SSO implementation may take months of dev time (i.e. $50k, minimum, considering cost of dev hours spent on it, and opportunity cost of not having those devs putting those hours into features).

And after you have done that, it remains an expensive feature - it's a high-touch feature that will eat product support time like you wouldn't believe.

Outsourcing this is still the cheapest option, and it still costs more than the product itself in many cases.

replies(1): >>43207230 #
3. rad_gruchalski ◴[] No.43207230[source]
I don’t understand your point. My question is: if the service provider offers SSO as an additional feature, why limit it to certain size of a client? Their service supports it. Why cannot my two persons company enable this feature? My two persons company can run my own keycloak and use it as an OAuth provider in your product all right. If you need months of dev time to enable SSO on my account then say that upfront because I will certainly find a different service provider because you clearly don’t know what you’re doing.
replies(1): >>43207689 #
4. lelanthran ◴[] No.43207689{3}[source]
> If you need months of dev time to enable SSO on my account then say that upfront because I will certainly find a different service provider because you clearly don’t know what you’re doing.

If you could do that, you would. The point is that SSO is high-touch and high-maintenance, and the price reflects that.

If it is as cheap you appear to think so, you'll make a killing offering SSO for businesses and undercutting the current providers by (maybe) 50%.

I don't think you are doing that. Maybe I am wrong, but if you are right you're leaving easy money on the table.