Today we released a rewrite major update of Saber Feedback’s web app.
We’re calling it “Saber Feedback version 2” but it is the same Saber Feedback with the same features, and a couple of new ones. It has an improved visual design and gives us ease and productivity when deploying fixes and improvements.
What changed
There’s the changes you don’t see and the changes you do see.
The changes you don’t see
Version 1 was a single-page application (SPA). It had two components:
- a JavaScript frontend built using a framework called Ember.js
- an API backend, created with Ruby on Rails.
In version 2 we’ve abandoned the SPA architecture.
Version 2 is a classic server-side rendered web application. Clicking on a button results in a trip to the server which fully renders a new web page and sends it to the user’s browser.
The changes you do see
Version 2 has a cleaner, simpler, more modern design, created by a professional designer. It also adds some improvements when viewing and managing feedback reports.
Our version 1 app looked like it was designed by a developer using the default Bootstrap 3 template. That’s because it was!
(Bootstrap is an HTML framework designed to help non-designers create a pretty good looking website with minimal effort.)
Bootstrap 3 was released eight years ago. So our site look dated. It also had the feel of a site created without professional input from a designer.
Why a major update?
A small, bootstrapped dev team should be able to move quickly. We are a small, bootstrapped dev team yet it felt like we were walking waist-deep through a swamp.
Adding new features and fixing bugs had become hard. Much harder than it should be.
There were two reasons for this:
- Any change, no matter how minor, such as adding a checkbox setting, required changing two apps: the Rails backend and the Ember.js frontend. Not too bad when things go right, but when they went wrong, troubleshooting was difficult.
- We were stuck in a tech impasse. The frameworks we used kept getting updated, yet we had stayed on the old versions that worked for us. This made sense in the short term, but long term, it had hurt us. We were in a difficult situation with Ember.js in particular, where it was hard to find good docs and skilled help with the version we had, but it was also hard to update to a new version.
We needed to do something: either update to the latest versions of all the frameworks we use - and keep staying up to date; or move to a tech stack that would be easier for us to work with.
This was a chance to remove the complexity of an SPA, and become the quick-moving team that we should be.
Why the SPA hate?
There’s no hate. SPAs (single-page applications) are great and certainly have their place. There are some incredible web apps that only exist because of the emergence of SPAs.
But SPAs add some extra complexity to the app development process that’s not always worth the cost.
A great team with good resources can do great things with an SPA. But there’s also a lot more that can go wrong.
In our case, we are a tiny team with limited resources.
A benefit of us being a tiny team is that we can be highly responsive to customer bug reports and feature requests.
Except this wasn’t happening. The complication of an SPA was holding us back from being the highly responsive team I want us to be.
For a regular B2B SaaS app, consisting of a collection of CRUD screens, there’s little to be gained by adding the extra complexity of an SPA to the development process.
If you are thinking of creating a B2B SaaS, I recommend not making it an SPA. Start with a classic server-rendered web app, unless you have an exceptionally good reason to use an SPA.
Don’t break anything!
Updating to version 2 was harder than you might think, because we have real customers using us daily for real work. In the rewrite major update, it was important not to cause disruption in their businesses.
I use several SaaS products daily in my business. I rely on them continuing to work the way I set them up to work.
I know the feeling of a SaaS product unexpectedly changing after a major update, and breaking my muscle memory and established processes.
I didn’t want our customers to have that experience with Saber Feedback. Anything that did work in the old version should continue to work the same way in the new version, more or less.
This idea of “don’t break anything” guided us in the rewrite major update.
There’s no announcement
Apart from this blog post you are reading, we won’t make any formal announcement of the updated app. No “we’ve got exciting news” email. No in-app popup or tutorial getting in anyone’s way.
You know what I do when I get a product announcement email that reads “Great news! We’re excited to tell you we’ve redesigned our app.”?
I usually delete it without reading it. I get lots of promotional email daily, and I’m sure our customers do too. I simply don’t read these emails unless they promise to offer me a strong benefit. What’s in it for me? Someone’s web app being prettier doesn’t really cut it when it comes to grabbing my attention.
What I do find interesting to me is when a product adds a feature that will make my life easier, particular a feature I’ve been requesting.
I think our customers would have no interest in an announcement that we’ve redesigned Saber Feedback.
We did add some a couple of new features, and we will announce them. But we’ll do that purely as individual announcements of new features.
Ideally we would not have added any new features while doing the rewrite major update. But I wanted there to be at least something of benefit to our customers. If any of them do contact us to say they don’t like the changes and want the old app, we have some improvements we can show them to justify the switchover.
In an ideal world, there’d be no big update
I don’t like releasing big software updates. In my career I’ve been involved in releases that are the culmination of months or years of work. And they are always painful. And stressful. They almost inevitably result in a blame game as to why the update didn’t go smoothly.
One of the many advantages of a SaaS product is you can release lots of small updates. You can deploy an updated product as often as you want, weekly, daily, or even multiple times a day. If the app breaks after a deploy you know the problem almost certainly lies in the most recent deploy. Because you only changed one thing, it is easy to find the problem.
And if finding the problem is hard, it easy to rollback to the previous deploy.
I would have preferred this iterative approach when updating Saber Feedback to the new version. But after some exploration it seemed that, in our case, we were going to have do a “Big Bang” update.
Because I wanted to turn an SPA into a classic web app, using a gradual approach would have added complications. With lots of internal resources, that would make sense. With our meagre resources, releasing a big change all at once seemed better in this particular case. I reluctantly accepted this.
I’m very happy to get the big update done. Now we can switch to the better approach of many small ongoing deploys.
You’ve got issues
We did some QA on the new app before releasing. We used a tester who had never used Saber Feedback, and had no preconceptions about how either the old version or new version should work.
I’m glad we did. The tester found some issues, we fixed the worst of them, but some minor issues exist.
We launched anyway. Here’s why:
- The old app also had issues, and fixing them was hard. We weren’t replacing a perfect app with an imperfect app. Both the old and new versions had issues. The sooner we could retire the old app, the better.
- The sooner we got the new app into the hands of real users, the quicker we can flush out problems our QA process missed. No matter how good one tester is, real-world users will find edge cases issues we never thought of.
- I wanted to move our v2 app to the “frequent small updates” model as soon as was reasonable. We can now make daily updates to our live app. In fact, since going live this morning, we have already deployed one minor improvement. The “frequent small updates” approach is a calmer, less stressful approach to product development for a tiny SaaS.
What’s next
What’s next is what I most enjoy in software development: an ongoing process of making and deploying iterative improvements to our product, based on customer feedback, that, over time, add up to a great product.
This will make Saber Feedback what I want it to be: a solid, stable, and simple product.