This week has been mostly about building! 🔨 

I also followed up with the leads I had already DMed, but without reaching out to new ones.

Table of Contents

• New onboarding flow for beta users

• Features usage tracking and quota

• Outreach stats update

• Beta users usage

  • Topics extraction

  • Generating threads

  • Scheduling threads

  • Thoughts on current usage

• When to launch?

• Conclusion

• Appendix

  • Personal branding

    • X

    • Beehiiv newsletter

New onboarding flow for beta users

Last week I shared how convoluted the onboarding process for beta users was. It required 5 touchpoints back and forth 🤯.

I wouldn’t be surprised if some lead didn’t follow up after the first answer because they felt overwhelmed by the actions required just to give EchoWords a try. This is an example of an interaction with a lead that didn’t follow up.

The lead ghosted me after that 😂.

Another issue was that once you were in, you were just seeing a blank screen like the one that follows.

I’m pretty sure that users can figure out what to do next, but it’s definitely not the best experience.

The last issue was that when integrating Beehiiv some users had trouble understanding whether it was properly done or not.

I tackled all of them one by one. 🚀 

There’s no need anymore for me to enable an account manually. I generated an invitation key that is passed as a parameter of the /sign-up URL and if the invitation key matches the account is automatically enabled. ✨ 

This makes the outreach way simpler in the eyes of the leads.

Once you’re in you also don’t need to figure out anymore what’s your next step as there’s a clear CTA.

Finally, when you need to integrate Beehiiv, you can also verify if the values that you put are supposed to work.

Not only does this improve the onboarding and the conversion from committed to beta users, but it also saves me a lot of time from follow-ups where I need to copy-paste over and over the same things.

It’s a win-win! 💪 

Features usage tracking and quota

I’m trying to build a business right? 😅 

This means that I need to track the usage of the features because different plans will have different quotas. Beta users have unlimited usage for now, but having this in place is mandatory by the launch.

Trying to execute an operation that exceeds the quota it’s aborted and a sticky notification on top of the viewport is shown. ❌ 

Implementing this required quite some effort, and this is definitely something that I’d need to add to my boilerplate.

I needed to add 5 new tables in the database and implement a big refactor of all the calls in the frontend to the BFF. The reason for the frontend changes is that so far I have only handled the happy path everywhere. 🤣

These are the new tables that I added.

A brief description:

• subscriptions: maps a profile with a plan and the corresponding start and end date. It also has a reference to the Stripe subscription object (now it’s always null).

• plans: name of the plan and reference to the Stripe plan object (now it’s always null).

• features: simply the name of the feature

• features_limits: maps a feature with its limit, represented as an integer, for a given plan. Because as I mentioned, each plan will have different limits.

• features_usage: maps a feature with its usage, represented as an integer, to a subscription. The mapping to a subscription has as a consequence also the information about the user owning the subscription, which in turn is mapped to the plan and the feature limit.

This setup will enable me to handle different scenarios and easily test them. 🚀 

Outreach stats update

As I anticipated, this week I didn’t outreach to any new leads, but followed up with those that didn’t answer and with some of them the second touch worked. ✨ 

These are the up-to-date stats:

• Outreaches: 89 (total DMs sent)

• Responses: 16 (number of people that replied)

• Qualified: 16 (number of respondents that qualified, last week I miscounted some that actually didn’t respond yet)

• Committed: 14 (number of qualified that verbally committed to try)

• Converted: 8 (number of committed that signed up)

This leads to:

• Response rate: 17% (responses / outreach)

• Qualification rate: 100% (qualified / responses)

• Verbal commitment rate: 87.5% (committed / qualified)

• Conversion rate: 57% (converted / committed)

These numbers are looking great! 🚀 

But again, the product is still free to use, so… I don’t know what to expect once it isn’t anymore. 😅 

Beta users usage

So, 8 persons signed up as beta users, but only 5 performed meaningful actions.

Let’s think about using EchoWords as a pipeline:

1. the user writes on the newsletter on Beehiiv (outside of EchoWords),

2. the user selects the new posts and extracts the topics,

3. the user picks a few topics to generate the thread,

4. the user schedules the thread.

Let’s now have a look at the usage of the main actions. 🔬 

Topics extraction

When you select a post and click on “Generate topics“, usually the number of extracted topics ranges from 5 to 15 depending on the content. This means that the total number of topics is not much significant of the users’ usage.

On the other hand, it’s more useful to see how many posts have been selected for generating threads.

The usage is quite low. But at the same time, most of the newsletters are published weekly and this could resonate. So I’d need to keep an eye on whether these numbers increase in the next weeks.

Generating threads

This is not looking that bad. For example, user 4 extracted topics only from one post, but generated 7 different threads from the extracted topics.

Scheduling threads

If I need to decide on a winner, then user 4 is definitely the one. 😂 

Jokes aside, he used the platform end-to-end, and by looking at the data he used it 5 days straight.

Thoughts on current usage

For sure I’ll reach out to have a more complete view of what they think about the product. So far I can tell that some users said they loved it, some didn’t comment but used it, some clearly mentioned that they’d used the “generate” feature, but would use the tool they’re already using for scheduling, etc.

Right now I’m busy wrapping up building what’s left for the launch, but next week I aim to get better feedback.

When to launch?

From a building perspective this is what’s left:

1. properly handle errors when the quota is exceeded for a given operation,

2. integrate and configure Stripe (I can re-use some stuff that I implemented already for NextCommit),

3. build the onboarding for the non-beta users.

Apart from these, I want to have the feedback from the current beta users, and then I’d need to prepare some marketing material for the launch like a better demo video, schedule on ProductHunt, etc.

I expect to finish building everything within 2 weeks (worst-case scenario), so ideally I could launch the week of the 22nd of July.

BUT…

On the 23rd of this month, I go to Bali for vacation! 🏖️ 😅 

There’s no way I’m launching immediately before leaving or when I’m abroad. 😅 

I’ll be back in mid-August and launching a product in August it’s probably not the best moment. 🤔

So maybe I’d wait directly for early September and in the meantime continue reaching out for new beta users? Or maybe, an alternative could be that I go out from the beta phase and start billing users, but without doing the proper launch.

I need to think about it, and I guess that the beta users’ feedback would impact my decision on what and when to do next.

Conclusion

I’m eager to wrap up the preparation for the launch and hear customers’ feedback! In the end, there’s no better validation than having paying users! 🚀 

Going to the Silicon Valley of the indie makers (Bali 🏖️) might bring some luck! Who knows, maybe I’ll come back with another new MVP! 😂 

I hope you enjoyed this week’s updates! 👋 

If you’re interested in following my journey, make sure to subscribe or follow me on X/Twitter and LinkedIn!

Appendix

Personal branding

X

<X premium analytics snapshot>

Beehiiv newsletter