We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Marc Köhlbrugge
PRO
@marc
Yes, all the (small) websites are hosted on the same server. People say Kamal isn't optimized for that, but it works fine for me.
I do host all databases separately using their managed services. You can include those in your Kamal server if you prefer, but for me I prefer having it managed for me so I have automatic backups, can easily login remotely via TablePlus, etc.
I tried Dokku quite a while ago and used it for some of my smaller apps for a while. I can't quite remember why I stopped using it. I think there was some limitation with regards to Postgres versions or something and once you want something they don't offer out-of-the-box, things get complicated.
These days I use Render for my largest app that require stability and where I can afford some higher price, and Kamal + Digital Ocean (and their hosted PostgreSQL instances) for some of my smaller apps that are all share the same servers, etc.
Kamal works for me, but took a while to figure out and get running consistently.
They are all different trade-offs. But if costs are important to you, I think Kamal is a decent option. Just prepare having to learn how it works, how Docker works, etc.
Good to know, thanks! Yeah, cost is the most important right now as many products are just getting off the ground.
I'm already familiar with Docker, just need to learn about Kamal. I take it you were able to configure Kamal to host everything on the same VPS for your smaller apps?
Yes, all the (small) websites are hosted on the same server. People say Kamal isn't optimized for that, but it works fine for me.
I do host all databases separately using their managed services. You can include those in your Kamal server if you prefer, but for me I prefer having it managed for me so I have automatic backups, can easily login remotely via TablePlus, etc.
Search for "email automation" as that seems like the tool you're after. User segmentation is a common feature, but not typically used to refer to these services.
One example is customer.io which I think has an affordable starter plan.
My first (and most successful) "directory site" is BetaList which I started in 2010.
It started off without any intent to monetize. I just wanted to provide a collection of up-and-coming startups because nothing like that existed back then.
People liked it, they signed up for the newsletter and kept coming back to the site everyday to discover new startups and apps to try.
Because I grew this captive audience of early adopters, companies started to notice and were willing to pay to get in front of those early adopters. Typical advertising model.
I didn't really market BetaList except for sending out a press release which got picked up by TechCrunch and got the ball rolling.
This type of website is really easy to start as the code is very simple (mine started out as a Tumblr blog) and the content is easy to get (just aggregate from various sources and/or ask people to submit their resource). Getting traffic (and later monetizing that) is a lot harder. As you will need to offer something that 1) enough people want, and 2) they aren't already being served. The fact that it's so simple to start a directory site means that it's hard to find opportunities that qualify. I think that's why most new directories fail.
The exception is when a new type of resource suddenly becomes relevant. Vision Directory (my most recent directory website) is such an example. When the Apple Vision Pro came out there was a sudden and unserved need. I tapped into that, got press coverage, and established the site as one of the go-to directories for Vision Pro apps. Anyone that's starting one now will have a hard time getting press coverage or mindshare, which means it's harder to get traffic, which means it's not that interesting for developers to submit their apps, which mean it's hard to monetize, etc, etc.
FWIW, I haven't monetized Vision Directory yet, because I don't think the numbers work yet (not enough people have an Apple Vision Pro and not that many apps are released), but I did start it with experience of running BetaList and knowing that as long as I'm one of the big players and get the traffic, there's a chance to monetize.
If you don't mind sharing, I'm curious about ballpark metrics on when you think Vision Directory would be able to monetize. Do you give create a specific deadline as a "trial" of sorts?
And what do you do if it doesn't hit that metric/deadline? Just leave the project hanging? Abandon it? Revisit later? etc.
I just play it by ear. No deadlines or goals. I think every project is different.
Vision Directory's growth is largely dependent on the success of Apple Vision Pro and the number of apps being developed for it. Right now, that's lower than expected. So I don't spend a ton of time on developing the site. But I keep it running in the hope that Apple Vision Pro will gain popularity and so will the site.
As for ballpark metrics, you can look at industry CPM rates. For example, if your industry has a $5 CPM that means you can charge about $5 per 1,000 ad views. So if your site has 50,000 pageviews per month, you can expect a ballpark of $250/mo in advertising revenue if you were to show one ad and have an advertiser lined up for the full month.
It's not a perfect science, especially at lower numbers, but it gives you a ballpark for advertising revenue.
For other types of revenue is really depends on your unique situation.
After verifying them locally etc, I follow this multiphase approach when introducing new email-sending functionality in production:
- Send every email to myself instead of user
- Send to user, and BCC myself
- Send only to user, remove my BCC
This lets me safely test the emails go out to the right people at the right time in the right format. I wait a few days or sometimes weeks between each phase.
I have the exact same strategy for #jomo , BCC'ed myself for a few days for all new email templates.
I still BCC myself for emails related to some features like student discounts, this way I know the pipeline for that feature is working from A to Z. This serves more as a "health check" in that situation.
I think separate sites makes sense if you have separate teams working on it. That way your marketing team can use a tool they are familiar with (e.g. Webflow) to create landing pages, run marketing experiments, etc. Without having to bother the engineering team working on the app.
If it's just you or a small team, I don't think it's worth the overhead of having to manage two apps, duplicating some of the styling, etc.
Thank you. I will look into this. It's possible the form is accidentally submitted twice, although it shouldn't happen as we disable the submit button after the first click.
Josef is too classy to include a link to his book, so I'll do it for him:
kamalmanual.com/handbook/
The purchase price pays itself back easily in the time you save.
Thanks Marc, I name you the official book ambassador :D