Weekly Indie Log #6

Hirvesh Munogee

April 01, 2024

· Updated April 05, 2024

5 min read

MRR Update
Marketing Week Killer Bug
Investigation
Throwing the Towel In
Not all Heroes Wear Capes
Continuing with Coding Week
Email Drip Sequence
Blog Deletion & On-Demand Sync
Show More

It’s Weekly Indie Log #6. I’ll be honest. Last week was meant to be marketing week but a pesky cache bug quickly torpedoed it into a coding week - an issue which threatened the value proposition of Stomod: unlimited posts and page views for your blog. Before we dive into the details, let’s first take a look at the MRR update.

MRR Update

This week we are at $239 MRR following a couple of new blogs created. The good thing with Stomod is that even if I do not get new subscribers, existing customers get charged per blog and each new blog created adds to the MRR.

Marketing Week Killer Bug

I started off last week with big plans for marketing week but I needed to investigate an issue reported by one of my customers about some 502 errors he was having on the blog. This made me very curious.

You see, blogs hosted on Stomod are intelligently cached on our CDN so that they are generated once and served from the CDN for up to a month if nothing changes in the blog content - with the blog posts periodically revalidated every 5 seconds.

The idea is that at any point in time, no matter the traffic your blog is getting, my origin server is only polled once every five seconds for a particular blog post.

When I heard of 502 errors, I saw that it aligned with some of the maintenance downtime I had planned for the Stomod app at app.stomod.com.

However, with my CDN setup, this should not affect blogs which should remain up.

Investigation

I started looking into the issue and quickly found out that for my customers using the /blog sub folder feature of hosting their blog under their main domain - for e.g. example.com/blog coupled with hosting on Vercel using the rewrites functionality in their vercel.json or next.config.json, Cloudflare (CF) cache status would always be MISS.

This initially got me thinking that it might be a misconfiguration from my side which was not allowing reverse-proxied URLs to be cached properly on CF since other domain mapping types were working properly.

After reviewing the configuration a thousand times and trying different configuration combinations, I couldn’t figure out what’s going on.

I then started thinking that maybe Vercel’s rewrites that was sending headers to CF which busted cached. I did some further testing and while I could see Cache-Control: max-age=0 on my server logs, I could not have CF properly ignore this header.

In retrospective, this led me down a rabbit hole where I got obsessed with this and how to resolve this when the issue was actually something else 👀.

Throwing the Towel In

Eventually, I just couldn’t understand why despite all my efforts, I couldn’t make CF cache Vercel reverse-proxied blogs. My head was spinning because I simply could not provide the value Stomod claims to provide if I could not leverage my CDN properly.

I decided that I needed help and reached out to CF support after day 3 of struggling with the issue (another mistake, should have done this earlier).

Not all Heroes Wear Capes

I reached out to CF on their Discord channel and got two support guys assisting me straight away. We started off by sharing details about what’s happening and the strange behavior being exhibited by CF cache.

Fortunately I had setup a test environment to replicate and test changes with backend access for log retrieval.

We overall debugged the issue together for 2 hours before one of the support engineers clocked that Vercel added additional headers to their rewrites which affects how CF caches pages.

Basically that header was causing each request to seem like a new one even though it was to the same page and hence causing a MISS on CF cache.

The support engineer provided a fix and I implemented that and boom, voila - everything was now being served under the CDN and one heavy burden was lifted from my shoulders. I was incredibly grateful to those support guys - to me heroes who saved me a big headache.

Continuing with Coding Week

Since the week was already kind of a coding week by then, I decided that hey, I should continue with the building and replace the marketing week with the upcoming coding week.

So after the cache bug hiatus, I managed to deliver some value for Stomod as well. Let’s take a look at what’s new below.

Email Drip Sequence

This kind of falls under marketing since I have had this in my todo since forever. The idea was to implement an email drip sequence for users signing up to Stomod.

The goal is to deliver well-timed emails at different points of a user’s Stomod journey to nudge them to the next right step.

For the limited time I had left in coding week, I decided to just get out a Welcome Email which would be sent 5 minutes after a user signed up for Stomod with some useful documentation links on how to get going.

The next thing planned for the email drip sequence is to devise a flow chart of the different points at which an email needs to be sent to users and roll that out in the next coding week.

Blog Deletion & On-Demand Sync

Customers are charged by blog created. Initially Stomod did not have a blog deletion feature build in. However now customers can delete blogs they do not need or created in error.

Another feature which I back-ported from AssistFlare is the whole site switcher component which allows users to sync their blogs on demand while also providing a nice intuitive interface for managing all their blogs, including creating/deleting blogs.

With this feature, users now have full control over their blog sync and can see the date/time when their blog was last synced, which was something of a grey area previously as this was not indicated anywhere on the admin side.