Well, two weeks ago, I went on vacation. Spent a lot of time outdoors, did almost no work, it was great.
And then I got back and promptly got hit by Covid.
Not exactly what I had planned. I was planning on doing an official launch this past week, but ended up not doing that because I was sleeping off Covid. But I do seem to be mostly recovered, so I’m attempting to catch up a bit this weekend. New goal: Product Hunt launch on Monday.
But the cool thing is that, even though I haven’t officially done a marketing launch of any size, I still have picked up a few paid users! At the moment, I have a total of 4 paid users. 2 users have subscribed at the $1/month tier, so I’m sitting at a jolly $2 MRR right now, which is a great start! And then I’ve had 2 users pay the $5 one time fee to quickly unfollow people in one shot, so deciding to add that was seemingly a good choice. Will be interesting to see if the numbers stay fairly even between the two or if one will end up being the primary way users pay.
Technical Challenges
Did end up coming up with a couple of cool solutions to issues that popped up.
Django Unhinged
The big issue that I faced was a weird one that I thought I had ironed out. And that was related to how to deal with users that had their account analyzed multiple times. Because I wanted to reflect the current state of the accounts they followed at the time of the analysis. And that turned out to be trickier than I thought it might be.
I’m using Django for the backend and it allows me to define Many To Many relationships implicitly. So I had a many to many relationship defined from my TwitterAccount model to itself. And there were related fields I could use to query those related objects. I tried to just set the following relationships to an empty list, which according to the documents, should work. And then I added a list of the accounts that followed.
But that didn’t stick sometimes. (And it was weird, because it was only certain times that it wouldn’t work properly) So I would call .set([]) on the model for the logged in account and it would get rid of all relations. But then any time I tried to add a related model to the list, it wouldn’t work. I fought this over and over, trying all sorts of different ways to fix it.
But in the end, I ended up using an explicitly defined model for the many to many relationship and just operating directly on that model instead of through the implicit model that was created. And now it works fine. Sometimes, it’s easier to just do things a different way. Still have no idea why the initial way didn’t work (and I spent a lot of time on it) and that will probably haunt me for the rest of my life. I really don’t like not understanding why something didn’t work the way I expected. But I’ve now got a working solution! So that’s awesome!
Raising a Bot Army Staff
One other improvement that I wanted to figure out: improve the performance of account lookups. I still have some work to do on the user experience when they first log in, but this improvement will help quite a bit. I’ve been creating a bunch of Twitter accounts lately, so that I can use them to register for Twitter developer accounts and get individual API keys because of the whole fiasco I had early on, where I broke my live app because of API limits.
So, as I was trying to figure out how to deal with rate limits, something occurred to me: why can’t I use all these extra accounts to help? So I turned my collection of accounts into a useful tool.
In actuality, I didn’t have to do a ton, a just duplicated my client account model and called it a staff account. Then I logged in with each of the accounts I wanted to put to work. That gave me the API keys I needed and I just copied those accounts into the staff table. Now, if I hit rate limits, I just loop through staff accounts until the job is completed (or I run out of staff accounts, but I can continue adding them as needed. I’ve only added 5 so far, but I still have about 3 or 4 more I can add, and I can always create more! I’ve gotten pretty adept at creating Twitter accounts over the last three months…)
Did catch myself, as I started thinking about how I could create a whole process around logging in staff users and adding them into the correct tables, but then ended up just doing things manually because it took me about 10 minutes. So I’m calling that a win!
Launch Day
Now that I’m decently well recovered and I’ve gotten things ironed out I’ve decided I’m just going to launch on Monday and see what happens. It’s as ready as it’s going to be at this point. I could keep tweaking things and reworking things, but I’ve got users that have confirmed it works and actually paid me, so that’s a good sign. Now, I’ve just got to see how well it converts from the landing page to the payment screen.
That’s the main thing I’m curious about. My current record is 0%, which my launch of Feather CRM. So anything above that, I’ll count as a win. The nice thing about a Product Hunt launch is that it guarantees a non-zero amount of traffic. And I do think that the users of Product Hunt are more likely than a person selected at random from elsewhere on the internet to be interested in Twitter tools to help them manage their follows.
So I’m going to set a goal of 10% traffic to paid user conversion. That’s probably super high, but I have no idea, so it’s a goal. We’ll see what happens.
I did get a good piece of feedback that I thought was interesting, too:
Factory Production Stats
Going to try out a new section. Let me know if you like it or not. But since I’m trying to create a factory that can crank out SaaS products, seems like it might be fun to keep track of certain stats to see how efficient the factory gets over time.
Current Products Live: 1
Total Revenue: $12
Recurring Revenue: $2 MRR
Paid Users: 4
That’s it for this issue! I’ll send out a reminder on Monday for the launch so that anyone who wants to help me spread the word will be able to do so!