Shutting Down NavHere
jeremyaboyd.com
jeremyaboyd.com
"What becomes less fun is the after-building part of running the business."
So many of us want to turn our hobbies into side-hustles, or even full companies. But once the "new" feeling wears off, or we finish building the product, it's just business. It's ALL business.
When your hobby becomes a job, a problem, a customer support problem day in and day out, the fun is gone.
I had games in the app stores. I started an escape room business. I tried to make what I love my job, and that all turned out to be "not fun" anymore.
So, now I'm trying to focus on game making, escape room building, etc, as a side project that I can share with friends and others for free and then just shut it down if it's not fun. I'll keep developing websites and being bored when I need to make money.
Edit: that doesn't mean it's bad to serve small clients, but if the concern is significant revenue....
The initial product was just an nginx config for me and Austin's shortlinks and domain forwards. And that actually ran just fine for months with no downtime.
Problem is then you get customers and you want to promise them no down time, so you have to allow for failovers and high availability, and that adds complexity that really isn't needed... until it is. And in the almost 3 years, we had 1 database fail over to a slave that got promoted to master, and actually stayed that way for months before I manually failed it back to the bigger server.
Even if it had worked out, it still really wasn't worth it to increase revenues by $9k unless I was closing this sized deal at least monthly.
If the service is worth 150k a year, you could of sold it for 75k. Then it becomes possible to hire someone else to handle the day to day.
I think you made the right choice, having 10$ a month clients who expect hours of support per month isn't practical.
"By the end of 2018, we had hundreds of free-trial users, and were serving 100s of thousands of forwarding requests each day."
This is probably my biggest learning through my own entrepreneurial journey. The days of "freemium" are over. Long live fast profitability!
NavHere's losses were a budgetary rounding error across my larger organization, and it did provide us customers that actually USED the system.
It was never meant to be a profit center or a loss leader, but I had hoped from the start it would cover the cost to run it.
It lost a total of around $1200/year, and that money would have just gone toward some other random business expense anyway that wouldn't have captured customers.
All in all I'd say it was a worthy loss, just not one I want to continue maintaining.
Looks like the real money would've been a premium plan which offered hands on support and setup for non-technical users.
This is a good thing, but doesn’t favor the new entrant. Go daddy’s service is aimed at the lowest of the low information level customer. If you help their customer you’ll need to provide oodles of support (as the poster experienced).
Converting the mass customers would have required an expensive ad campaign because most people who need the product don’t even know to look for it.
The poster was able to get a tiny number of knowledgeable customers which proves the value of the product. But getting paid for that value is hard.
Then it would just sit there, despite the fact that it could probably be sold for $15k/mo, because that's not a skill I have. If someone signs up for $15k/mo, it's worth a couple extra afternoons to make it more robust for them.
I'm pretty sure you could have done the same, but selling this stuff is a pretty difficult task!
e: another thing you could do is resell domains through it; you wouldn't be competing with registrar builtins then.
The original code was only a single nginx config to fix the problem on my sites, when I realized there were others having the issue, I built out an application.
If I were redoing it today, I'd probably just have a running caddy server since it does HTTPS as well.
48 src/301.c
Anyone want to pay $15k/mo?
Looking back, I shouldn't have ever scaled it beyond my personal needs, and kept the architecture simpler, and not "highly available". Cost would have been only 10% since that service could run on a single $5 droplet running Caddy server
It was quite the adrenaline rush getting our first few signups, but then it was so sad seeing it not get traction. We learned a lot though!
It’s well documented that making systems distributed to achieve high availability very often actually reduces availability, because distributed systems failure modes are gnarly, and so there’s just a lot more complexity in the system as a whole, a lot more moving pieces to go wrong. (Relatedly, it is also well understood that error-handling code is about the buggiest code out there.)
For starters, I can’t think of any reason to separate web application server from forwarding servers, so that’d lop it by one.
Then I’d lop the three database servers and put them on the forwarding servers as well, with something like a simple streaming replica arrangement if I was keeping both of the forwarding servers rather than reducing it to one.
This is pretty much guaranteed to be more robust, because now requests are depending on one machine only, perhaps with a second just hanging out in the background paying attention to what’s going on; whereas in your distributed system, there are at least two machines that can take things down by failing (if the DB server you’re talking to goes down, it’ll still be a short time before the system sorts itself out and switches to another one).
I would love kernel live patching to be better understood, tooled and used; then you could safely keep your single machine up indefinitely, just gracefully restarting your HTTP servers and databases as needed. As it is, if you go down to a single box, you’ll want to do the occasional quick restart. Ten seconds of downtime every so often doesn’t feel too terrible to me, and if you happened to have an HTTP proxy in front of you it might even turn that into just a slow request. But yeah, the second server might be warranted so you can avoid this altogether: just switch which server is the primary and direct all traffic to it, and then freely reboot what is now the standby machine.
It was overly complicated for robustness. I tested multiple database crashes, servers going down in one zone, and it would always fail over just fine, because application code would connect to a slave if it could not connect to the master, so forwards would work, unless there were multiple outages in multiple data centers.
Now switching the floating IP to the backup forwarder did take about 5 seconds, and I could have made that better by putting a proxy in front, but I'm just moving the point of failure up a level, and it was never needed anyway.
It sounds like you’ve tested the simple failure modes, machines dropping off altogether, which is good; but I’d still be sceptical about the system’s robustness, because those aren’t the interesting failure modes, and the interesting failure modes are the ones that give the most trouble. Systems are easy when a node is there or not there, but when a node becomes unreliable (e.g. overloaded or network troubles of a variety of kinds), that’s when the real trouble happens, and when it’s most common that measures that were supposed to make things available actually make them unavailable. (This stuff is hard.) That’s why avoiding a distributed architecture until you actually need it can be well worthwhile.
I would use something like Caddy which manages it's own config and has an API for live updates.
SQLite for the user management and administration.
I would possibly have 2 Caddy nodes though, with a LB between them (instead of my potentially flawed heartbeat floating IP mechanism). The application would do an atomic update to both Caddy servers, if either failed, it would roll it back.
But you are still looking at around $30-40/mo for hosting, not saving much money, but making it much simpler and saving headaches.
Let's say you are trying to capture keywords in a domain and path for luxury highrise apartments in NYC's Tribeca neighborhood, you might buy the domain newyorkluxuryhighriseapartments.com and point the link /tribeca-luxury-apartments/ to a highrise you have in Tribeca.
Or maybe the domain you have wanted forever finally went up for grabs, you buy it, and move your blog over to it, but now all of the links to your old domain are broken. Now you need to forward the old requests to the new blog.
But lets say you are a company and have bought another company, and have folded all of their content under different url structures into your website, you now need to point their old URLs to the new blog posts/product pages/knowledge base/etc.