First learnings and the importance of reducing the switching costs

The demos were insightful and highlighted two key points:

First, I initially marketed Slap as a tool to build a customer support platform on Notion—my original reason for creating it. But the Notion consultants I spoke with had other needs that matched Slap’s features, like CRM, task management, and shared inboxes. I updated the website and revised my email content to reflect these broader use cases.

Second, for consultants to promote Slap, the product had to be quick and easy to test with minimal risk or switching costs. After all, how could they trust Slap to still be around in a month or a year? We were just starting out. If using Slap meant significant workflow changes or the risk of losing important conversations, it would be much harder to convince them.

At the time, Slap created a new email address for users to share with their clients for support tickets and information requests. This required users to adjust their workflows and risk losing data if Slap shut down.

Those first demos made it clear: reducing switching costs was crucial. If Slap could work with existing client email addresses, adoption would be much easier.

We revisited tools like Pipedrive and Intercom, and suddenly, the solution was obvious. Adapting Slap to work with existing email addresses required significant code changes, but it solved issues like adding custom domains and managing email deliverability. More importantly, it reduced the risk and investment needed for users to adopt Slap.

With that, we started building MVP V2.