Looking at my last issue, I realize how crazy things can change in a week. 😅 

Today I’ll cover some thoughts I had during this week about EchoWords.

Table of Contents

• Very first marketing email

• A too-complex stack

  • The SSR and BFF scam

    • The EchoWords app doesn’t need SEO

    • The BFF for the Python API

    • SSR impact on SEO

• Painkiller or vitamin?

• Conclusion

• Appendix

  • Personal branding

    • X

    • Beehiiv newsletter

Very first marketing email

This week I sent my very first marketing email! 🥳 

When a user signs up to EchoWords, it is automatically subscribed to a list that I handle with MailerLite. This is the first time I’m sending an email from MailerLite.

You can see the content below, but in short, I wanted to thank all the beta users that used the product so far and announce the upcoming launch. I also transparently show them both the “standard” pricing and the discounted one they claim as a gift for being a beta user. 🎁 

Those who are interested will need to come back to me and I’ll share the Stripe payment link.

Out of 9 beta users, 1 verbally committed to be interested in continuing using the product, but didn’t convert yet, 1 unsubscribed from the mailing list, and the rest didn’t answer. 😭 

Is it just too early? Or maybe it’s just not good enough? I’ll share more about this by the end of this issue. In the meantime, they will have until 2 weeks post-launch to claim their discount.

On the other hand, I got a few feature requests from different users, and the main ones are:

• ability to attach images to posts (right now it’s text-only),

• automatically add a CTA at the end of a thread (e.g. “Subscribe to my newsletter <link>“)

These all make a lot of sense, and I started working on the possibility of attaching media. 🎉 

A too-complex stack

As I just mentioned, I started working on attaching media to posts, but I’m realizing the stack I’m using now is overly complex. 😭 

The SSR and BFF scam

When I was working with NextCommit I realized how important was SEO given that many pages were open to the public. For this reason, when I started EchoWords I decided to early-optimize that part by using a stack that would allow me to do SSR (Server-Side Rendering) as that should help optimize SEO.

There are multiple caveats, and I’ll cover them one by one:

1. EchoWords is a product fully behind a login,

2. the need for a BFF due to my API being in Python,

3. does SSR really play such a big difference when it comes to SEO?

The EchoWords app doesn’t need SEO

Compared to NextCommit, EchoWords is fully behind a login. This means that SEO is not relevant at all when it comes to deciding whether to adopt SSR or not. Yeah, I know, SSR is not only about SEO, but that was the main reason why I considered adopting it. The problem with SSR is also that is not as handy to debug and troubleshoot compared to a non-SSR approach. The development experience has been bad for me, and this impacts the pace I can develop. This means impacting adding features or fixing bugs for my users which is the most important thing.

Keep in mind that when I say that EchoWords doesn’t need SEO I’m talking about the app itself. However, it would be fundamental for content marketing purposes for a companion blog to attract organic traffic. However, that would be a different application, and in that case, I’d probably go for fully static pages.

The BFF for the Python API

For the development of APIs I always use Python for the same reason: I’m just more comfortable with it, hence, faster (don't tell me to write the API in JS/TS 😂). But doing SSR already requires you to have a Node server, so I ended up having:

1. a React app,

2. a Node server for the SSR,

3. a Python server for the API.

Since the React app is already communicating with the Node server, I decided to adopt a BFF approach where the Node server also acts as a proxy for the Python API. This has multiple advantages:

1. you keep the business logic on the BFF, and the Python API can just have the CRUD endpoints,

2. you minimize the amount of HTTP calls needed by the React app as you can make the SRR + BFF render everything needed all at once.

Initially, I loved this architecture! ❤️

These two points were solving problems I also faced in previous companies: better parallelizing the development by better splitting business logic from the pure API logic and minimizing the amount of parallel HTTP calls from the application (browsers have a limit of parallel HTTP calls).

It would work great with multiple teams, but it just doesn’t help me work faster moving alone.

As an example, sometimes I just need to expose a CRUD endpoint on the API. This implies also writing the layer on the BFF, which kinda duplicates the logic, and only then attaches the logic on the app. Then the error handling needs to be aligned between API and BFF, etc.. In general, it’s a nightmare for non-trivial features. 🤯 

Don’t take me wrong, SSR has its place. Especially if your whole stack is in JS/TS then that would also come as a free bonus.

SSR impact on SEO

This is something that I read everywhere, but tbh I don’t know how much impact it has.

For all these reasons I’m reworking my boilerplate to use a Vite CSR application + Python API. 🚀 

Painkiller or vitamin?

EchoWords started because I needed it. When I started working on it, I didn’t have much expectations, and since then I got quite a few interested persons, and the cold reach stats have been good so far. But the CTA was testing the product for free as a beta user which is a different commitment from paying to use it. 😬 

While eagerly waiting for the launch on ProductHunt scheduled for next week, I couldn’t help but think more in-depth about it as a business.

Is EchoWords a vitamin or a painkiller? 🤔 

The first problem of EchoWords is about recurring usage. How often does a publisher post on a newsletter? Once a week? Maybe 2 or 3 times a week at the very most. Repurposing content is indeed a pain, but is it worth paying for a product for repurposing content that you publish at most 2 or 3 times a week? Especially considering that nowadays it repurposes only on a single platform (X/Twitter). It saves time, no doubt, but probably not that much to be considered as a painkiller.

I started thinking backward to understand what problem I needed to solve. Repurposing content on social media it’s just a way to get visibility as the owner to: distribute your product, find leads, and convert them.

I’m pretty sure that the problem is a great one to be solved. Everyone trying to run a business either as a solopreneur, as a company, as a creator, or as an agency, is looking for leads.

The question is:

In the case of EchoWords the business owner is the publisher, the product type is the newsletter, and the lead origin is X/Twitter. I need to find the combination that feels this problem the most and target them.

For all these reasons I’m also getting back to the whiteboard and considering whether I should pivot EchoWords to something else. 🤔 

Conclusion

By next week EchoWords will be launched already, so I will definitely have some interesting insights to share! 🥁 

In the meantime, I’ll continue reworking my stack as an investment to move faster for future projects and EchoWords and be on top of the beta users. 🤞

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

Appendix

Personal branding

X

Beehiiv newsletter