16 ms·

Why I’m rewriting my SaaS

103 points by reillychase 7y ago

deedubaya 7y ago
Cringe. Solo entrepreneur full-rewrites are almost always churn inducing, feature stagnation, time sucks. I'd advocate working on improvements to the current platform, one-by-one. Focus on features that increase your bottom line until you're at a MRR where losing 30% of your customers will be worth the cost of improvements.
- pgeorgi 7y ago
  I wouldn't describe in such harsh words (although maybe that helps bring the point across?), but overall I agree. Several of the items look like they could be improved completely isolated from the rest (eg. the email issue). Moving from Wordpress to Laravel means that the basic stack remains the same (PHP). All in all, this looks like something that ought to be possible without a rewrite. I'd start with building a new front router that calls liberally into wordpress as a backend. Once wordpress is only managed (and accessible!) by the front router, one by one hack up wordpress to call into Laravel Spark stuff (eg. the user database) instead of using its own infrastructure. The end result would be that there's no wordpress code being used anymore (so drop it), and the site is completely moved over. But that way every step in between won't be a regression to users, and it's realistic to add the odd emergency feature addition to the platform without having to maintain it twice (in the old platform and the new).
- stevekemp 7y ago
  Agreed. I've been slowly migrating away from my one-true-love, of Perl, because it is easier to deploy golang binaries. During the course of that I've isolated small sections of my project, and migrated them over a piece at time. Instead of perl "doing stuff" it now writes out data to JSON, and a golang service consumes that and does the actual back-end work. This lets me rewrite the trickiest bits first, and also provides a level of isolation and abstraction I can test thoroughly. Already I'm feeling much more productive, and I have more confidence that I don't need to install specific versions of gems (some ruby stuff too) and "unsupported" perl modules.
- dang 7y ago
  > Cringe. Please don't do that here. It breaks the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
bluedino 7y ago
Sounds like a plan. Looking forward to reading the 'lessons learned' blog post in 6-12-24 months.
- throwaway66666 7y ago
  Touché and well played. I am on the camp that big rewrites are more often than not a mistake. The real reason behind most rewrites is that writing code is easier than reading code. A system has grown to be too complex to understand, and instead of taking the time to study and understand it, you start writing it from scratch instead. At some point you end up with a new system of perhaps comparable complexity as the original. You now understand that system better, but give it enough time you will get rusty, or new devs will join that do not understand it. Rinse and repeat. Also many devs underestimate the reasons why code has ended up being smelly. Unaccounted edge cases, legacy system support, time constraints. Who says you won't hit time constraints during the rewrite too? Of course there are many good reasons for a rewrite too. Being more experienced and a better dev today than you were yesterday when you wrote it, is a great way to clean up whatever amateur mistakes you might have created. Or perhaps the system is inefficient and now you know how to improve it. But incremental updates, and defining the critical code path and making sure that is as robust as possible (eg I am sure you can increase system performance by magnitudes by changing only 10% of the most-often run code), are great ways to start. Good luck, and I am looking forward lessons learnt too!
  - bluedino 7y ago
    The worst is reading the code, understanding it, then re-writing it in $LANGUAGE. Then you have a (buggy) emulation of the original product. I believe a re-write should be a new product. New accounts will use it, and old ones will be migrated to it. Chances are, the way you did things the first time around wasn't ideal (but you couldn't have known back then), so the process is improving and not just the code.
jdsully 7y ago
This Joel on Software article “Things You Should Never Do” is quite timeless and worth a good read. The first one is never to rewrite your software. Your just giving your competitors a free break. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- underdeserver 7y ago
  Not sure why this was downvoted. This is truth, and applies entirely to the original post.
  - deleted 7y ago
    [deleted]
  - twblalock 7y ago
    Maybe it was downvoted when you saw it, but it isn't now. Maybe it will be downvoted again next time someone sees it. Who knows? This is why it's a bad idea to complain about downvotes.
    - jdsully 7y ago
      It was down-voted because I didn't explain why the article was relevant. I added the last two sentences a bit later.
- raviojha 7y ago
  This! OP, please consider thinking over this before you set out on the voyage.
  - reillychase 7y ago
    Great post, and appreciate what he is saying. But in this case I'm kind of locked into WordPress and the plugins I'm using. It will be much easier to start over with Laravel Spark which will give me more control. From there, I agree that it should never be rewritten again, only refactored.
deleted 7y ago
[deleted]
TheRealPomax 7y ago
This should be "HostiFi 2.0: Why I’m completely rewriting my $5,735 MRR SaaS". There is no reason to leave off the actual name of the thing that's being worked on.
mixmastamyk 7y ago
Despite the title, it doesn't appear he'll be waiting for a complete rewrite. The article discusses replacing a number of subsystems. I'd be surprised if one could pull it off simultaneously. Much more likely they will be tackled sequentially. This is similiar to refactoring, just at a larger scale.
- reillychase 7y ago
  It really is a complete rewrite - switching from WordPress to Laravel (no code being reworked really there ...) and then rewriting the backend Python scripts to be OOP (minimal code reuse)
  - mixmastamyk 7y ago
    Rewrites of subsystems, one at a time, is not as risky as a wholesale rewrite, which Joel warns about. Some parts may be harder/riskier than others of course. Python scripts to OOP might reuse a lot depending on how it was written.
gravypod 7y ago
Why not slowly decompose the functionality of your software into modules, abstract those behind some kind of abstract interface, and then move those abstracted modules into microservices when the time comes? Just by slowly rebuilding components as you need to touch them you'll be able to maintain some velocity on feature development, be able to incrementally test your changes to the codebase, and actually find the real world logical groupings of functionality (rather than guessing on business domain like most SOAs do). Full rewrites like this are a pain, high risk, and always take longer than expected (feature creep/deployment/etc)
- bwilliams 7y ago
  Rewriting piecemeal is a great idea but extracting microservices adds a whole new set of problems that likely aren't worth the tradeoff, especially when your team is just you or only few other people. eg: Now your devops responsibilities aren't just deploying and keeping 1 app up and running, it's all of them.
  - gravypod 7y ago
    I specifically mention this in reference to "when the time comes". Sometimes the devops work is worth it. If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc. It's all trade offs and just choosing when you want to make them. If adding 10k QPS load to your monolithic app is going to cost more than the (TOOLS + DEPLOYMENT STRATEGY + INTEGRATION TESTING + ETC) then it's worth pulling it out.
    - bwilliams 7y ago
      I 100% agree it's all trade-offs. I think cost is important, but in that scenario it's going to cost them a lot more in time to split out and maintain several services. Devops was only one example. Their development speed will also likely slow down by a good margin as they now have to worry about inter-service communication and all that comes with it (keeping schemas aligned, making sure the services can actually talk to one another, etc.). I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.
mjwhansen 7y ago
An unfortunate truth of solo/duo entrepreneuring is that things get created and written quick and dirty. You simply don't have the time to do everything by the book, especially when you're nights/weekends. Getting to the point when you have to do a massive refactor is, in a way, a mark of success because it means you're growing and have a good customer base.
- a13n 7y ago
  You can and should build a big codebase (as far as early stage startups go) without doing things quick and dirty. The additional time is an investment that will save you far more time down the road.
  - cpitman 7y ago
    But what if the product is a flop? Part of the benefit of "quick and dirty" is that you can quickly verify the market and iterate on product fit.
    - rabidrat 7y ago
      Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough? Remember Friendster from 2003? It's quite possible that it would have not lost to Tribe/Myspace/Facebook if it didn't take minutes to connect before eventually timing out. There are things that are worse than wasted effort, and one of them is a hockey stick that slips right through your fingers. By the time the curve is inflecting, if you can't keep up, you're burning customers and inviting competition. If you have to rewrite at that point, you are going to lose to competitors with deeper pockets and no PR baggage.
      - zeroxfe 7y ago
        > Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough? Poorly-designed hit any day. Was this a trick question? :-) (Obv, I'd prefer a well-designed hit, but I'd rather move fast and validate my market with a hack, than spend too much time and energy building something good that'll never be used.)
dusing 7y ago
We just did this with our mobile app, which was in Phone gap, and is now in React Native. It was a horribly long process, I would have liked to avoid but I don't think there was much choice. We were able to purge unused features that had previously added complexity. Building a new app with 4yrs of knowledge from the previous app was enlightening. Now that we are through it, I feel the product is better for it, but damn it took too long.
- weaksauce 7y ago
  Where could you have been had you focused on cleaning up your existing codebase?
  - dusing 7y ago
    Debated that a lot, but it was determined that Phone Gap had no future
duxup 7y ago
I've recently been using freshdesk and while it is nice like a lot of support platforms I feel like everything is ultra clicky and I'm constantly clicking not knowing what will happen or unexpected things change in the view. Its a thing with all support platforms it seems. Also... please people can we move off medium so I can stop getting spammy stuff about joining and etc? Clearly this person is a professional but at this point medium seems like using facebook to post a professional blog or something where this / that.
- reillychase 7y ago
  I'm actually looking at using Intercom now instead of FreshDesk, FreshChat, and Drip. Sorry about Medium lol I'm just lazy. I plan to get around to hosting my own blog on Ghost.
  - duxup 7y ago
    No problem, I get why people use it, it's just grown.. less than a desirable place to read things.
- fastball 7y ago
  Using Medium is good for SEO. It's one reason why people still use it.
  - duxup 7y ago
    On top of the annoying stuff on Medium... I feel like using it for SEO also means that it is being posted "at" me and not "for" me. That is to say they post because they want me to visit their business site ... not really tell me a story. Now for any given user (the OP here) I wouldn't accuse them of that and I'm sure they'd like me to visit their site, but also want to genuinely share... but overall I start getting a different feeling from Medium posts... Reminds me of when I was getting started with web development. SO MANY basics articles out there that I'm pretty sure are just resume fodder written by people who aren't that much better than me, and really not written to share as much as post on their resume, that really kinda sucks.
hombre_fatal 7y ago
I've done various rewrites of solo and duo projects. Once all is settled, I ultimately tend to agree that I should've probably upgraded what I originally had, Ship of Theseus style. But then again, I also wasn't doing that, and the allure of a rewrite is what energized me to do all the work in the first place. But I recognize this blog post as the sort of giddy excitement that you use to convince yourself that it's going to help your customers and be worth your time. Just look at it: all upsides, no downsides. Tread carefully, OP.
stanmancan 7y ago
User email accounts aren’t exactly designed to send procedural emails from your application. I would use something like Postmark or AWS SES to send emails from your application instead of just dropping in the SMTP credentials for your Rackspace email.
Implicated 7y ago
> I will switch from self-hosting my email to $2.99/month email accounts at Rackspace. As someone who has spent the last year or so migrating consulting clients off of Rackspace services - I have to ask... Why Rackspace email?
- reillychase 7y ago
  No reason really. What would you suggest?
  - travelton 7y ago
    Not OP, but my $0.02... GSuite or O365. GSuite: Best in class spam filtering. Mail clients are excellent. Integration with the rest of the Google ecosystem is wonderful. Google, as an auth provider, is fantastic. Downtime is nearly non-existent. O365: Enterprise class mail tools, sub-par protection (spam and phishing will get through). Mail clients are fine. Even better if you're a Windows shop. O365, as an auth provider, is not as clean. Not as fault tolerant, but getting much better.
    - ultrarunner 7y ago
      I wonder— at a time in the future when every email in the country passes through a Google server, will they finally bring back Wave?
  - gremlinsinc 7y ago
    I really like zohomail suite. Pretty similar to gmail, I pay like $12/year for the lite plan.
ozten 7y ago
> I’ve always hosted all of my email on my own servers just to save money. > I will switch from self-hosting my email to $2.99/month email accounts at Rackspace. I think this is really smart, assuming Rackspace does a good job of delivering mail. I don't think self-hosting email ever makes sense from a cost savings perspective. What is you're time worth? A single hiccup and you've blown base $3 per month or heck $50 per month in cost savings. I currently point the MX records of all my domains to my existing Fastmail account.
honopu 7y ago
I personally wouldn't bet on rackspace being around long term and I wouldn't start today building email on their platform. We've dealt with rackspace for years, we're mostly off of it now.
- reillychase 7y ago
  Good to know. Recommendation instead?
  - seniorThrowaway 7y ago
    I like mailgun but I only use their free tier.
    - hittaruki 7y ago
      Mailgun is owned by rackspace. https://en.wikipedia.org/wiki/Rackspace#Acquisitions https://en.wikipedia.org/wiki/Rackspace#Acquisitions
      - travelton 7y ago
        Correction... Was. It's an independent company now. https://www.mailgun.com/blog/mailgun-becomes-an-independent-company https://www.mailgun.com/blog/mailgun-becomes-an-independent-...
joking 7y ago
I quite curious about your motivations and product, as I work on custom hotspot which is bigger enough that current offers are outside scope but also we have just the basic features and adding things like facebook login support and marketing info capture with the gpdr in mind are difficult to prioritize. Anyway, a full rewrite is always a complicated task as always are more things that what one thinks ahead, but good luck with it!
heroic 7y ago
Rackspace email? Why not gsuite?
projectramo 7y ago
I'm very interested in the first version you wrote. It just seems like a good example of an MVP. You got the site up in Wordpress fairly quickly, modified it using PHP to your liking (did you have to in order to implement features), and then some python to actually do some work on the back end? Very unclear, but I think that would be of interest to this audience. edit: Apparently the rest of his blog is dedicated to this info so in case you are reading this, are as curious as I was, and didn't think to click around: https://medium.com/@reillychase https://medium.com/@reillychase
karmakaze 7y ago
Of all the things in the rewrite which are essential to the need to rewrite, which would be feasible to replace later, and which fall in between? Minimize scope ruthlessly. It's always easy to expand scope when a core is working not the other way around. Even if the entire 2.0 system was complete the migration without impacting customers seems intricate. Staged infra updates FTW.
stunt 7y ago
I enjoy seeing successful examples like your project. Many of the successful products started simple like you did, while there are tones of over-engineered MVPs that never launched. Cheers!

103 points by reillychase 7y ago

Cringe. Solo entrepreneur full-rewrites are almost always churn inducing, feature stagnation, time sucks. I'd advocate working on improvements to the current platform, one-by-one. Focus on features that increase your bottom line until you're at a MRR where losing 30% of your customers will be worth the cost of improvements.

pgeorgi 7y ago
I wouldn't describe in such harsh words (although maybe that helps bring the point across?), but overall I agree. Several of the items look like they could be improved completely isolated from the rest (eg. the email issue). Moving from Wordpress to Laravel means that the basic stack remains the same (PHP). All in all, this looks like something that ought to be possible without a rewrite. I'd start with building a new front router that calls liberally into wordpress as a backend. Once wordpress is only managed (and accessible!) by the front router, one by one hack up wordpress to call into Laravel Spark stuff (eg. the user database) instead of using its own infrastructure. The end result would be that there's no wordpress code being used anymore (so drop it), and the site is completely moved over. But that way every step in between won't be a regression to users, and it's realistic to add the odd emergency feature addition to the platform without having to maintain it twice (in the old platform and the new).
stevekemp 7y ago
Agreed. I've been slowly migrating away from my one-true-love, of Perl, because it is easier to deploy golang binaries. During the course of that I've isolated small sections of my project, and migrated them over a piece at time. Instead of perl "doing stuff" it now writes out data to JSON, and a golang service consumes that and does the actual back-end work. This lets me rewrite the trickiest bits first, and also provides a level of isolation and abstraction I can test thoroughly. Already I'm feeling much more productive, and I have more confidence that I don't need to install specific versions of gems (some ruby stuff too) and "unsupported" perl modules.
dang 7y ago
> Cringe. Please don't do that here. It breaks the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

bluedino 7y ago

Sounds like a plan. Looking forward to reading the 'lessons learned' blog post in 6-12-24 months.

throwaway66666 7y ago
Touché and well played. I am on the camp that big rewrites are more often than not a mistake. The real reason behind most rewrites is that writing code is easier than reading code. A system has grown to be too complex to understand, and instead of taking the time to study and understand it, you start writing it from scratch instead. At some point you end up with a new system of perhaps comparable complexity as the original. You now understand that system better, but give it enough time you will get rusty, or new devs will join that do not understand it. Rinse and repeat. Also many devs underestimate the reasons why code has ended up being smelly. Unaccounted edge cases, legacy system support, time constraints. Who says you won't hit time constraints during the rewrite too? Of course there are many good reasons for a rewrite too. Being more experienced and a better dev today than you were yesterday when you wrote it, is a great way to clean up whatever amateur mistakes you might have created. Or perhaps the system is inefficient and now you know how to improve it. But incremental updates, and defining the critical code path and making sure that is as robust as possible (eg I am sure you can increase system performance by magnitudes by changing only 10% of the most-often run code), are great ways to start. Good luck, and I am looking forward lessons learnt too!
- bluedino 7y ago
  The worst is reading the code, understanding it, then re-writing it in $LANGUAGE. Then you have a (buggy) emulation of the original product. I believe a re-write should be a new product. New accounts will use it, and old ones will be migrated to it. Chances are, the way you did things the first time around wasn't ideal (but you couldn't have known back then), so the process is improving and not just the code.

jdsully 7y ago

This Joel on Software article “Things You Should Never Do” is quite timeless and worth a good read. The first one is never to rewrite your software. Your just giving your competitors a free break. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

underdeserver 7y ago
Not sure why this was downvoted. This is truth, and applies entirely to the original post.
- deleted 7y ago
  [deleted]
- twblalock 7y ago
  Maybe it was downvoted when you saw it, but it isn't now. Maybe it will be downvoted again next time someone sees it. Who knows? This is why it's a bad idea to complain about downvotes.
  - jdsully 7y ago
    It was down-voted because I didn't explain why the article was relevant. I added the last two sentences a bit later.
raviojha 7y ago
This! OP, please consider thinking over this before you set out on the voyage.
- reillychase 7y ago
  Great post, and appreciate what he is saying. But in this case I'm kind of locked into WordPress and the plugins I'm using. It will be much easier to start over with Laravel Spark which will give me more control. From there, I agree that it should never be rewritten again, only refactored.

deleted 7y ago

[deleted]

TheRealPomax 7y ago

This should be "HostiFi 2.0: Why I’m completely rewriting my $5,735 MRR SaaS". There is no reason to leave off the actual name of the thing that's being worked on.

mixmastamyk 7y ago

Despite the title, it doesn't appear he'll be waiting for a complete rewrite. The article discusses replacing a number of subsystems. I'd be surprised if one could pull it off simultaneously. Much more likely they will be tackled sequentially. This is similiar to refactoring, just at a larger scale.

reillychase 7y ago
It really is a complete rewrite - switching from WordPress to Laravel (no code being reworked really there ...) and then rewriting the backend Python scripts to be OOP (minimal code reuse)
- mixmastamyk 7y ago
  Rewrites of subsystems, one at a time, is not as risky as a wholesale rewrite, which Joel warns about. Some parts may be harder/riskier than others of course. Python scripts to OOP might reuse a lot depending on how it was written.

gravypod 7y ago

Why not slowly decompose the functionality of your software into modules, abstract those behind some kind of abstract interface, and then move those abstracted modules into microservices when the time comes? Just by slowly rebuilding components as you need to touch them you'll be able to maintain some velocity on feature development, be able to incrementally test your changes to the codebase, and actually find the real world logical groupings of functionality (rather than guessing on business domain like most SOAs do). Full rewrites like this are a pain, high risk, and always take longer than expected (feature creep/deployment/etc)

bwilliams 7y ago
Rewriting piecemeal is a great idea but extracting microservices adds a whole new set of problems that likely aren't worth the tradeoff, especially when your team is just you or only few other people. eg: Now your devops responsibilities aren't just deploying and keeping 1 app up and running, it's all of them.
- gravypod 7y ago
  I specifically mention this in reference to "when the time comes". Sometimes the devops work is worth it. If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc. It's all trade offs and just choosing when you want to make them. If adding 10k QPS load to your monolithic app is going to cost more than the (TOOLS + DEPLOYMENT STRATEGY + INTEGRATION TESTING + ETC) then it's worth pulling it out.
  - bwilliams 7y ago
    I 100% agree it's all trade-offs. I think cost is important, but in that scenario it's going to cost them a lot more in time to split out and maintain several services. Devops was only one example. Their development speed will also likely slow down by a good margin as they now have to worry about inter-service communication and all that comes with it (keeping schemas aligned, making sure the services can actually talk to one another, etc.). I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.

mjwhansen 7y ago

An unfortunate truth of solo/duo entrepreneuring is that things get created and written quick and dirty. You simply don't have the time to do everything by the book, especially when you're nights/weekends. Getting to the point when you have to do a massive refactor is, in a way, a mark of success because it means you're growing and have a good customer base.

a13n 7y ago
You can and should build a big codebase (as far as early stage startups go) without doing things quick and dirty. The additional time is an investment that will save you far more time down the road.
- cpitman 7y ago
  But what if the product is a flop? Part of the benefit of "quick and dirty" is that you can quickly verify the market and iterate on product fit.
  - rabidrat 7y ago
    Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough? Remember Friendster from 2003? It's quite possible that it would have not lost to Tribe/Myspace/Facebook if it didn't take minutes to connect before eventually timing out. There are things that are worse than wasted effort, and one of them is a hockey stick that slips right through your fingers. By the time the curve is inflecting, if you can't keep up, you're burning customers and inviting competition. If you have to rewrite at that point, you are going to lose to competitors with deeper pockets and no PR baggage.
    - zeroxfe 7y ago
      > Would you rather have a well-designed flop, or a poorly-designed hit that you can't scale fast enough? Poorly-designed hit any day. Was this a trick question? :-) (Obv, I'd prefer a well-designed hit, but I'd rather move fast and validate my market with a hack, than spend too much time and energy building something good that'll never be used.)

dusing 7y ago

We just did this with our mobile app, which was in Phone gap, and is now in React Native. It was a horribly long process, I would have liked to avoid but I don't think there was much choice. We were able to purge unused features that had previously added complexity. Building a new app with 4yrs of knowledge from the previous app was enlightening. Now that we are through it, I feel the product is better for it, but damn it took too long.

weaksauce 7y ago
Where could you have been had you focused on cleaning up your existing codebase?
- dusing 7y ago
  Debated that a lot, but it was determined that Phone Gap had no future

duxup 7y ago

I've recently been using freshdesk and while it is nice like a lot of support platforms I feel like everything is ultra clicky and I'm constantly clicking not knowing what will happen or unexpected things change in the view. Its a thing with all support platforms it seems. Also... please people can we move off medium so I can stop getting spammy stuff about joining and etc? Clearly this person is a professional but at this point medium seems like using facebook to post a professional blog or something where this / that.

reillychase 7y ago
I'm actually looking at using Intercom now instead of FreshDesk, FreshChat, and Drip. Sorry about Medium lol I'm just lazy. I plan to get around to hosting my own blog on Ghost.
- duxup 7y ago
  No problem, I get why people use it, it's just grown.. less than a desirable place to read things.
fastball 7y ago
Using Medium is good for SEO. It's one reason why people still use it.
- duxup 7y ago
  On top of the annoying stuff on Medium... I feel like using it for SEO also means that it is being posted "at" me and not "for" me. That is to say they post because they want me to visit their business site ... not really tell me a story. Now for any given user (the OP here) I wouldn't accuse them of that and I'm sure they'd like me to visit their site, but also want to genuinely share... but overall I start getting a different feeling from Medium posts... Reminds me of when I was getting started with web development. SO MANY basics articles out there that I'm pretty sure are just resume fodder written by people who aren't that much better than me, and really not written to share as much as post on their resume, that really kinda sucks.

hombre_fatal 7y ago

I've done various rewrites of solo and duo projects. Once all is settled, I ultimately tend to agree that I should've probably upgraded what I originally had, Ship of Theseus style. But then again, I also wasn't doing that, and the allure of a rewrite is what energized me to do all the work in the first place. But I recognize this blog post as the sort of giddy excitement that you use to convince yourself that it's going to help your customers and be worth your time. Just look at it: all upsides, no downsides. Tread carefully, OP.

stanmancan 7y ago

User email accounts aren’t exactly designed to send procedural emails from your application. I would use something like Postmark or AWS SES to send emails from your application instead of just dropping in the SMTP credentials for your Rackspace email.

Implicated 7y ago

> I will switch from self-hosting my email to $2.99/month email accounts at Rackspace. As someone who has spent the last year or so migrating consulting clients off of Rackspace services - I have to ask... Why Rackspace email?

reillychase 7y ago
No reason really. What would you suggest?
- travelton 7y ago
  Not OP, but my $0.02... GSuite or O365. GSuite: Best in class spam filtering. Mail clients are excellent. Integration with the rest of the Google ecosystem is wonderful. Google, as an auth provider, is fantastic. Downtime is nearly non-existent. O365: Enterprise class mail tools, sub-par protection (spam and phishing will get through). Mail clients are fine. Even better if you're a Windows shop. O365, as an auth provider, is not as clean. Not as fault tolerant, but getting much better.
  - ultrarunner 7y ago
    I wonder— at a time in the future when every email in the country passes through a Google server, will they finally bring back Wave?
- gremlinsinc 7y ago
  I really like zohomail suite. Pretty similar to gmail, I pay like $12/year for the lite plan.

ozten 7y ago

> I’ve always hosted all of my email on my own servers just to save money. > I will switch from self-hosting my email to $2.99/month email accounts at Rackspace. I think this is really smart, assuming Rackspace does a good job of delivering mail. I don't think self-hosting email ever makes sense from a cost savings perspective. What is you're time worth? A single hiccup and you've blown base $3 per month or heck $50 per month in cost savings. I currently point the MX records of all my domains to my existing Fastmail account.

honopu 7y ago

I personally wouldn't bet on rackspace being around long term and I wouldn't start today building email on their platform. We've dealt with rackspace for years, we're mostly off of it now.

reillychase 7y ago
Good to know. Recommendation instead?
- seniorThrowaway 7y ago
  I like mailgun but I only use their free tier.
  - hittaruki 7y ago
    Mailgun is owned by rackspace. https://en.wikipedia.org/wiki/Rackspace#Acquisitions https://en.wikipedia.org/wiki/Rackspace#Acquisitions
    - travelton 7y ago
      Correction... Was. It's an independent company now. https://www.mailgun.com/blog/mailgun-becomes-an-independent-company https://www.mailgun.com/blog/mailgun-becomes-an-independent-...

joking 7y ago

I quite curious about your motivations and product, as I work on custom hotspot which is bigger enough that current offers are outside scope but also we have just the basic features and adding things like facebook login support and marketing info capture with the gpdr in mind are difficult to prioritize. Anyway, a full rewrite is always a complicated task as always are more things that what one thinks ahead, but good luck with it!

heroic 7y ago

Rackspace email? Why not gsuite?

projectramo 7y ago

I'm very interested in the first version you wrote. It just seems like a good example of an MVP. You got the site up in Wordpress fairly quickly, modified it using PHP to your liking (did you have to in order to implement features), and then some python to actually do some work on the back end? Very unclear, but I think that would be of interest to this audience. edit: Apparently the rest of his blog is dedicated to this info so in case you are reading this, are as curious as I was, and didn't think to click around: https://medium.com/@reillychase https://medium.com/@reillychase

karmakaze 7y ago

Of all the things in the rewrite which are essential to the need to rewrite, which would be feasible to replace later, and which fall in between? Minimize scope ruthlessly. It's always easy to expand scope when a core is working not the other way around. Even if the entire 2.0 system was complete the migration without impacting customers seems intricate. Staged infra updates FTW.

stunt 7y ago

I enjoy seeing successful examples like your project. Many of the successful products started simple like you did, while there are tones of over-engineered MVPs that never launched. Cheers!