Hacker News new | ask | show | jobs
by jmduke 2442 days ago
This post resonates a lot with me!

I've got a side project that's current bringing in around ~2-3K MRR (https://buttondown.email).

I spent a long time daydreaming about having it hit four-digits in recurring revenue — it felt like such an accomplishment that if I were able to crack it, it'd be a dream come true. It's certainly not enough to live off of (especially living in Seattle), but it's a non-trivial amount of money and gives me a great source of pride.

The idea of doubling that amount, though, seems — well, if not _exhausting_, certainly unappealing. I can't think of a way in which my life would be improved by additional revenue, but I can think of a lot of ways it would be hampered by having twice the customer base:

1. More customer support and time spent writing emails

2. More time working on features that aren't what I care about

3. Less freedom to experiment with other projects or ideas

One of the joys of having a project that is truly _yours_ is that you alone get to dictate your terms of success.

9 comments

Have you experimented with removing your free plan? Curious to know what your support-time is in relation free:paid plans. Just from my anecdotal experience free-plans attracted the wrong type of customer for me, switching to paid with a free trial worked much better. When you have a large team and can built fancy funnels to make freemium work it seems like a great idea from a marketing perspective but for small(ish) companies I really doubt the numbers (% of upgrades from free to paid after a certain period of time) make sense in a lot of cases.
I think this is one of things where my Business Brain 100% agrees with you (the majority of my customer support burden comes from free plans, though it's worth pointing out something like two-thirds of my paid cohort converted from free) but my Hacker Brain things this project _should_ have a free plan, because free plans are nice and good and neat.
>my Hacker Brain things this project _should_ have a free plan, because free plans are nice and good and neat.

I agree free stuff is neat. I think the other side of the hacker ethos is "figure it out yourself", so I would never expect someone who hacked something together and shared it for free to then provide support for said thing. That's cool if you want to do it, but seems like asking for burnout unless you really like the support side or perhaps are looking at turning it from a free thing into a business, as you seem to be.

When somebody from free needs support, wouldn't that be a good time to "Upgrade for support or reach us on Twitter"
Depends on the person providing the thing. If you're ready to build some revenue from your thing, then yeah, upselling free customers when they need support seems like the natural thing to do.

However, there's another breed of hackers that enjoys making things more than they enjoy making money from things they make (which involves a different set of skills and interests). In which case, it's also valid to just say, "Sorry it's hard, but I can't commit to formal support."

Yeah, I think you did a better job of describing my dichotomy than I did. The galaxy brain corollary, though, is that if I get _too_ many folks who are asking for free-tier support, it means I can't support everyone at the level I'd like to; sort of a microscopic version of the OSS labor crisis.
I addressed this with my side business by keeping the free option pretty limited. Only a very small set of my potential customers qualify for free (very small, volunteer orgs, with very small problem spaces), so their support burden is kept pretty low. I still feel good about being able to offer something free to folks that get some value but can't afford to pay anything, but I'm not overwhelmed by ungrateful masses.
A little second-hand anecdata: my sister works for one of the big email marketing companies and from what I've heard from her the tagging features are a _big_ thing for customers. You could perhaps try shifting "tagging" to the paid subscription or somehow constrain the tagging on free plans?
Oooh, interesting. That's good to keep in mind — thanks.
You could run an experiment and track the data. Three cohorts: paid, free, trialing. Data points per cohort: customer support tickets per 100 accounts, conversion rate, ARPU, LTV, churn %.

I think you'll be surprised at the results. At the very least your hacker brain will be more informed, especially if you put a dollar figure on your customer support time. Doesn't have to be anything fancy, it could even be minimum wage.

A lot of small business don't nearly have the customer base to make statistically significant claims about their business.
this is obviously my cheap opinion and I am looking to get to the point where you are with my side project: I think you could have the best of both worlds by getting rid of your free plan. The key would be to wind down your free plan in a way that is respectful to your current users and you could do this by offering them a steep discount on the first year's terms or giving them ample time to make a decision once you discontinue the free plan.

You have probably enough word of mouth now and establishment to build off of with your product that you can get some new customers without it. You can always do trials or free POC periods.

Above you felt the tradeoff to get to higher revenue was more support work (not worth it).

But perhaps the real tradeoff you're making, is to do more support work in order to allow the free tier?

Hey Jmduke,

Others have pointed out about the free plan and I mostly agree with them.

One thing that hasn't been mentioned yet is the opportunity to position your product as the alternative for people that think mailchimp is just too much. Tell me this on the headline. "The easiest way to run your newsletter." sounds generic. Maybe something like "Write and click send, that's all it takes. No templates, no extra steps."

Finding people that want to send a simple newsletter without all the steps of mailchimp should be easier. Tell your customers early that you will handle the migration part and you might find more conversions as well.

Write Click Send. I like it. it's not even registered as a .com (or maybe I shouldn't say that out loud)
Can confirm, someone bought this today through Google domains. I had the thought to do exactly that as soon as I read this. That's quite an OG domain, you should have bought it.
Consider hiring a virtual personal assistant and delegating the low impact, high (time) cost tasks. There will be an inherent limit to how much money you can make if you try to do it alone.

If you truly want to learn to build a business, realize that you aren't a software developer anymore. You're a businessperson and thats completely different. It's a different field and you can have a lot of fun learning it. It's a reward experience.

I say this from experience. I grew my company from 2-3k MRR and did it all myself. It was only when I realized I needed to hire myself out of low level tasks and focus on the important things did I start to make real strides. It wasn't long before I was well beyond that MRR level (now have 6 employees)

Something I've found helpful is to make a list every day of the tasks you completed, and circle anything you could've delegated. This is then an iterative process to help you improve your delegation skills, which should allow you to focus specifically on business tasks that provide the most leverage.
This is a great approach. And one must resist the urge to "just do it myself" because it'll take too long to explain to someone else or you want it done just right. I used to do that to, as do most software engineer turn founders.

In those cases you should take the time to write a detailed how-to document to complete the task along with a checklist of items that should individually be true/complete in order to call the task as a whole complete. Instructions/code for a human to execute.

That "system" (how to) and "control" (checklist) forms the operational basis for most companies that scale nationally and will remove a significant amount of stress and work for the founder.

This is a really good idea, and I'm going to start doing it; thanks.
Can I ask - how do you send emails programmatically? Every time I've done this for personal projects, I run into issues. Whether it's auth blocking from GMail or whatever. Seriously would appreciate even just a nudge in the right direction.
Not OP but I've spent a lot of time setting up email sending for SaaS apps. It shouldn't be too difficult, just use a third party provider like sendgrid and make sure your DKIM and SPF records are setup properly and you should be good to go. I've also used stuff like Amazon SES and it's not worth the trouble for side projects (or even medium sized, real businesses, honestly). If you have specific questions feel free to ask.
Hey there -

How would I setup a "native" email system. I don't want to use some third party that I have to pay for. I'd like to be able to send the "raw" email myself.

So for example my current system uses Java + GMail's SMTP server. I have to pass it a username+password, and I can send basic emails that way. There are at least 2 major problems with this setup:

1) So far, all I have done is send REALLY basic 100% test based emails. It's not exactly clear to me how I would send a fully baked HTML email.

2) Consistently GMail BLOCKS my username. It requires me to manually go in at least every few days and enable "Allow less secure applications"

Basically you don't. It's a really big challenge to create a consistently non-blocked email sending service, especially if you host on a big cloud provider like AWS.

Sounds like you are using the Gmail API. To be honest that's not really fit for sending transactional emails, and is increasingly unfit for 3rd party consumption due to API restrictions.

Sendgrid also has a free tier that may work for your use case if the app is for a very limited audience, other than that you're kind of asking "how do I get something really difficult for free?"

Well, how does Sendgrid do it?
Sendgrid uses a mail transfer agent like Postfix or PowerMTA (I don't actually know what they use but I wouldn't be surprised if it was PowerMTA) to talk to receiving email servers via SMTP.

It's not hard to set up the technical bits to send email. You basically just need to run an MTA that knows how to stamp your outgoing messages with DKIM (a cryptographic signature). Your server has to have an SSL certificate. You also need SPF records set up that accurately reflect what servers are allowed to send on your behalf. DMARC records are helpful as well but not required. If you're only sending as yourself, that's basically it. You should be able to get mail through to the big receivers without much trouble (maybe having to mark "not spam" a few times to start).

The trick to maintaining your sending reputation as an individual is to not send email for anyone else and never send content that you don't control. Sendgrid sends for other people and they have people on staff who's full time job is to fight with the big receivers to maintain their reputation.

Sendgrid puts a huge amount of money and resources into maintaining both technical and political legitimacy. They have relationships with other major senders and receivers of email, they follow every single rule to the T, they aggressively police their own IPs (of which they have many) etc. It's a complicated business, which is why it's totally worth it to pay them to do it for you.
Create an app password [0], and then use something like ssmtp for sending the mail.

Your app then then just call out to ssmtp, passing in the relevant mail information (to, from, subject, message, etc).

0: https://support.google.com/accounts/answer/185833?hl=en

(Email noob here) I'm writing a very low traffic web app, and I was thinking about SES, mostly because it's free for small volumes. What's wrong with it? Would you recommend sendgrid (or something else) instead?
I recently set up SES for my own projects so some this info is fresh in my mind. I’m not an SES power user so ymmv.

My only real, big issue with SES is with email templates as in I don’t know of any way to view templates in SES.

So, if you create an email template and want to preview it, you’ll have to do it locally/off-SES. If you need to handle hundreds of templates, this can get tedious.

The other minor tech issue is that SES needs you to work out of one of three regions - US east, west, and EU (if I recall correctly).

If, for legal or hygiene purposes you need your data anywhere else in the world, you’re SOL.

Other than these two, SES has been amazing. It costs pennies and I host all my email, both transactional and personal, with them. Worth noting that my transactional email is in the order of a few hundred per month, if that.

I’m a little biased (being the CEO) but check out EmailOctopus. We connect to Amazon SES and if you've got fewer than 2,500 contacts/subscribers you'll be on our free tier.

https://emailoctopus.com/amazon-ses

My experience has just been that SES is a little less user friendly to setup and debug. It's not a huge deal, you'll probably be fine.
I'm using a combination of Mailgun and Postmark to send emails, and heartily recommend them both.
A combination of? Aren't they largely the same product? I'm just curious why you'd be using both.
Not the OP but I wouldn't be surprised if they use both for different purposes. Postmark has extremely high delivery rates but is very particular about primarily sending transactional email like account updates, receipts, etc. They did recently add bulk API messages but it seems like a higher tier feature.

Mailgun is much more flexible about what they allow to go through their servers, but they have correspondingly lower delivery rates.

Yup, precisely. I use Postmark for transactional emails and a very small subset of bulk emails; Mailgun handles everything else.
Just took a look at your landing page, cool idea -- one element of your service that really stood out was down at the bottom "Free concierge onboarding".

Really interesting offer. Do you find new subscribers take you up on this a lot? Seems like a great way to improve your migration tooling!

Hey I use your product! Thank you for making it.
What the deliverabiltiy story of your app?
Do you worry that Substack is going to eat your userbase here?
Cool