
Why I’m rewriting my SaaS - reillychase
https://medium.com/hostifi/hostifi-2-0-why-im-completely-rewriting-my-5-735-mrr-saas-d2744734b42e
======
gravypod
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)

~~~
Chris_Newton
_Full rewrites like this are a pain, high risk, and always take longer than
expected (feature creep /deployment/etc)_

This is accepted wisdom in large parts of the software development world, but
I have become sceptical about treating it as a universal rule.

In the end, all software maintenance means rewriting part of the system at
some scale, whether it’s a one-line bug fix or a Big Rewrite of the whole
world. Both the risks and the potential benefits typically increase with the
scale of the job, so how much of the system to change in one go is always a
cost/benefit question.

All software maintenance where we delete or modify old code risks losing
subtle bug fixes and behaviour tweaks that have accumulated in that code.
However, it also gives us a chance to make the new code more systematic and to
take into account additional knowledge gained and better tools that have
become available since the older version was written. This means the new
version also has an opportunity to eliminate subtle bugs and awkward edge
cases that have accumulated in the old code.

For me, one of the times when a relatively large rewrite is indicated is when
there are big changes to the foundations on which the system or some part of
it is built: you need to support new hardware or run on a new operating
system, there’s a big update to your programming language available and you
want to be able to use it, the protocols or APIs or data models used to
interact with other systems have changed. Another is when the original
software architecture has been outgrown and technical debt is severely
affecting productivity. In this case, it appears that both of those factors
may apply, so maybe a wide-reaching update does make sense.

~~~
lugg
I'm of a similar mind but tend towards avoiding rewrites, mostly because I
find refactoring more efficient.

And with that in mind, I should clarify im not opposed to a complete gutting
of a legacy codebase and I'm not afraid of doing it in a full rewrite sense of
the word either. I just like to have a strategy and keep master green
throughout.

> risks losing subtle bug fixes and behaviour tweaks that have accumulated in
> that code.

This shouldn't be happening in a sufficiently tested or sufficiently
understood system and I feel like using it as an excuse to not rewrite is a
lack of reasoning skills.

Full rewrites are a waste of time because you end up spending way more time
than expected making useless decisions around the edges about APIs that really
don't matter that much.

Or you end up finding out your dream design has a fatal flaw. Or you end up
just porting a bunch of boiler plate.

Rule of thumb,

If you can't figure out a peicemeal way to refactor what you have into what
you want you want, you have no business discussing what a rewrite should
entail.

And a caveat to all this, I know a couple of teams that rewrite every system
on a two year schedule. They do this as a a way to stay nimble. I believe
their feature set and domain requirements are well known. This sort of setup
has a few benefits and traits I like. Most notably the fact design skills are
constantly being flexed instead of stagnating. Junior devs are made into
seniors with this process.

~~~
Chris_Newton
_I 'm of a similar mind but tend towards avoiding rewrites, mostly because I
find refactoring more efficient._

Interesting choice of phrase. What would you say is the difference between
refactoring and rewriting, assuming we’re talking about keeping the externally
observable behaviour of the affected part of the system the same in each case?

 _This shouldn 't be happening in a sufficiently tested or sufficiently
understood system_

Perhaps, but as systems and the teams that develop them evolve over time, it
is all but inevitable that some knowledge and understanding are lost. You’ll
never have perfect documentation. You’ll never have tests for every possible
case. You’ll never have an unambiguous and readily located comment for every
subtle detail in the code that someone seven years ago spent a couple of hours
thinking about before they put finger to keyboard, when three other people
have since refactored that code, generalised its interface, and fixed a
performance glitch in a dependency so some aspects of the original design
became unnecessary. Preserving knowledge and understanding as well as possible
is one of the challenges facing any team with a long-lived system.

Those losses are a form of technical debt, and as it accumulates, two things
happen. First, the original code becomes harder to maintain and develop.
Second, the original code becomes more risky to rewrite. So unfortunately,
there’s a fairly high probability in practice that a part of a system that has
become sufficiently difficult that a large-scale rewrite is being considered
will also be a part of the system where the current development team have
incomplete understanding of the current implementation.

 _If you can 't figure out a peicemeal way to refactor what you have into what
you want you want, you have no business discussing what a rewrite should
entail._

But how do you do a piecemeal refactoring exercise if, say, you’re moving to a
new programming language? I had to rewrite a large part of a relatively
complicated web UI a few years ago, like for like. Although it had been
working reasonably well to that point and the design was quite clean and had
stood the test of time, it was built around a Java applet. That design made
sense when we were first implementing that system, at a time when JS was slow
and many features we take for granted in browsers today weren’t yet widely
supported. It was less helpful when the great and the good of the browser
world decided that Java applets were a liability and they were going to make
them harder and harder to use until eventually they killed them off
completely. Now, we did have a clean, careful interface between the applet and
the various other parts of the page that were written in JS, so we only had to
redo that part of the system. However, we had no choice but to reimplement
everything the applet did, using alternatives like JS and SVG, starting from
scratch. This is the sort of scenario I was talking about before when I
mentioned changes in the foundations of a system.

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

~~~
throwaway66666
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
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.

------
hombre_fatal
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.

------
mjwhansen
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
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.

~~~
zild3d
this only applies when you "know" that what you're building will stick around.
If you are quickly iterating on an MVP it's more likely that code you write is
going to need to be totally revamped.

Acquiring tech debt in an early stage startup often results in never having to
pay back that debt

~~~
a13n
Not true. In the case that your MVP is actually worth something, you don't
want to be spending all your time paying off tech debt when you could be
focusing on growth.

~~~
jrs235
Quick honest question, what's your exposure and familiarity to finance?

------
mixmastamyk
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
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
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.

------
dusing
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
Where could you have been had you focused on cleaning up your existing
codebase?

~~~
dusing
Debated that a lot, but it was determined that Phone Gap had no future

------
stanmancan
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.

------
duxup
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
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
No problem, I get why people use it, it's just grown.. less than a desirable
place to read things.

------
ozten
> 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.

------
karmakaze
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.

------
projectramo
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)

------
Implicated
> 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
No reason really. What would you suggest?

~~~
travelton
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
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?

------
honopu
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
Good to know. Recommendation instead?

~~~
seniorThrowaway
I like mailgun but I only use their free tier.

~~~
hittaruki
Mailgun is owned by rackspace.
[https://en.wikipedia.org/wiki/Rackspace#Acquisitions](https://en.wikipedia.org/wiki/Rackspace#Acquisitions)

~~~
travelton
Correction... Was. It's an independent company now.
[https://www.mailgun.com/blog/mailgun-becomes-an-
independent-...](https://www.mailgun.com/blog/mailgun-becomes-an-independent-
company)

------
joking
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!

------
jdsully
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-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
growtofill
Joel’s conclusions were based on a single data point. There were successful
rewrites as well: [https://medium.com/@herbcaudill/lessons-from-6-software-
rewr...](https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-
stories-635e4c8f7c22)

In particular, Basecamp successful rewrite seems more applicable here, since
both are web services. They never sunset previous two versions though.

Edit: typo.

~~~
jdsully
Actually it was based on multiple datapoints: Netscape, Quattro Pro, Arago,
and Microsoft Word.

------
stunt
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!

------
deedubaya
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
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).

------
heroic
Rackspace email? Why not gsuite?

------
TheRealPomax
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.

