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!
First, to the question about team sizes. We view "Startups" as generally teams with <25 users, followed by small/mid-sized "Growth" companies that have <250 employees. Beyond that, we anticipate most companies falling into the "Scale" category. That said, this could all be revised based on usage data and I will also update our website later today to reflect the above.
Regarding pricing, we haven’t finalized it yet because we’ve prioritized understanding how teams actually use emdash—what works, what doesn’t, and where we should focus.
Pricing is important, and we want to get it right. Typical usage patterns, evolving AI and cloud/infra costs, and where we fit competitively in the market are all variables we still need to explore. We’ll need to strike the right balance and be competitive enough with vis-a-vis the market.
It would be smart to start with a free trial before transitioning users to a paid plan. We’re still figuring out whether that should be time-based (e.g., 60-90 days), usage-based (e.g., after your 20th video meeting).
I get it – no one likes unexpected pricing shifts and when the time comes, we will be transparent about our thinking and communicate changes well in advance. Our goal is to build something sustainable, not just for us, but for the teams that rely on emdash. Hope this helps clarify.
We probably over-invested in some details, but we believe those small touches add up, kind of like getting that nice “thunk” when closing a well-built car door. Glad you noticed the polish—it’s something we really care about!
Care to share what's the average size of your early adopters? Because it seems to be something great for larger teams but, then again I imagine the friction is greater for them too.
Early adopters range in size from 2 people to ~20. As you said, the Catch-22 for larger teams usually have established tool stacks so the (operational) switching cost is prohibitive.
FWIW we are a team of 5 and already find the feature set useful (we're biased, of course). I expect that ~5 is the threshold the organizational and search features become invaluable.
That said, most customers tell us they’d rather focus their resources on their core business vs manage every tool themselves. Even those who’ve tried self-hosting haven’t necessarily seen better uptime vs Slack.
Just pick something that's a no brainier for people to try, change it later if you have to. Your biggest risk right now is people walk without giving the product real consideration. Lack of clarity on pricing will do that for a lot of people, even though you are offering a free trial.
I'll also note, I've yet to work for a place that would even consider paying for the teams pro stuff, and I haven't seen it at any of our clients either, so I'm really curious to know see how big the market is for this
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.
Key things for support are:
1. Ability to share access to the customers machine with out any hassle and easy acknowledgement for sharing access
2. Recordings and summarirs automatically gets added to tickets and issues
3. Playbooks are handy for the support engineer during the call
Being able to tag chats with keywords would be nice. Being able to pull chats into docs easily would be nice. Being able to pull chats into more than one doc -- not just move, but tag/reference/copy. Global tags (with ACLs) as well as team and personal tags (also with ACLs) would be fantastic. Don't forget read and access ACLs, not just write ACLs.
Email integration would be nice. Emails -> IM, so I can read IMs and emails in one app. IM -> email (right-click on a range of messages, click send, get placed in $MUA and edit).
Don't forget retention controls, support for on-prem, etc.
Tagging is another organizational feature that is on our roadmap and has always made sense to me. Right now our organizational model is primarily hierarchical which has obvious limitations.
RE: email integration - We have a pretty robust email integration right now. Neville was always insistent that we shouldn't force people into the app to have a conversation, especially for one-off collaborators who get looped into a chat. They can stay blissfully ignorant of the fact that the conversation is actually happening on emdash if it suits them.
To your specific points:
#1 makes a lot of sense and I sense the "low friction" part of this is the key distinction.
#2 is something we have thought about through the lens of a yet to be built Zapier integration. This would effectively allow you to create more custom methods to route data from emdash into your CRM/other systems of record for customers. Curious if this approach would be interesting.
#3 is in theory supported today. There are several ways you could store/share playbooks for support engineers. For example, you can create a Team and upload the playbooks as shared resources.
Security is not a differentiation method. It's table stakes for any technical product. That's what the above linked website explains.
In my opinion, SSO tax results in arbitrary denial of employing best practices for these businesses.
Passwords are evil, because people generally don't care about security or don't have the capacity to employ proper hygiene around passwords. This likely means that SSO tax indirectly contributes to an increased number of account compromises (especially in small businesses, because more limited funds means more limited security; they're low-hanging fruit for bad actors).
Sounds like you're a filer (I am too). Sounds like emdash is kind of a mix of filing and piling.
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.
Companies don't "bother with" SSO because using SSO is expensive, since every product charges more for the privilege. Otherwise there's no reason why a 2-person company shouldn't be using SSO from the get go.
It's not a binary flag, it's a spectrum. "Defense in depth" is a thing, and that means a layered approach to security.
Just because a product is missing SSO does not in any way mean that that product fails any security check.
IMO, holding the position that not having SSO is the same as not having security is unreasonable.
Missing SSO does not magically make the other $FOO layers of your security vanish into the ether.
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.
I'm genuinely excited that you're in this space now, too, as I myself have had my nose to the grindstone building out what the collaboration app for distributed teams that I've always wanted. We need options/competition in this space; just this year alone, I've had a little over a a dozen conversations with interested folks in teams across the United States working in industries from agricultural sensors manufacturing to game studios for hire, and the same pain points that you and I were reasoning about back at Slack are the same pain points that users still unwillingly tolerate.
See you around--and good luck out there!
PS. As an English major I'd be remiss to not share that I love the name emdash. :D
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.
Wishing you the best with your work — I’ll be keeping an eye out for your launch. Good luck!