Skip to main content

By Emily Kassmeier

Lessons Learned From Rebuilding Two SaaS Apps

In 2019, Zaengle acquired two SaaS products. Since then, we rebuilt both products and, earlier this year, they relaunched.

You can read the story here.

The process to rebuild Workify and Growth Geeks had its fair share of ups and downs. Today we’re hitting a few highlights of the lessons we learned along the way.

Understanding the user is crucial.

After the acquisition went through, we spent the next few months getting a better understanding of the products and who was using them. We sent surveys, talked with people in the support queue, took inventory of the available data, and got on calls with the service providers — all with the goal of understanding a few key things:

  1. Who were our users?
  2. Why were they using the product? What was it helping them accomplish?
  3. What did they think was working about the current product? What did they think wasn’t working?

The product ecosystem was brand new to us, so we needed to take time to fully understand it before we jumped in and started changing big things. Without knowing our users, we would’ve been taking shots in the dark trying to make their experience better. Only after we embarked on a fact-finding mission to better understand the products could we determine how to move forward from there.

Document pretty much everything.

These two SaaS products have many layers and support multiple user types, so it was important for us to get organized early on to keep track of all the details. We created spreadsheets covering numerous topics like services, subscription types, and user feedback, plus lists of protocols for our support queue and user help center, observations from our own QA testing, and much more.

We didn’t create lists just to make lists though. The documentation had to serve a purpose.

These docs helped us stay on top of all the moving parts for each app and they revealed opportunities for us to improve upon the existing setup. For example, documenting a full list of the third-party tools used helped us identify areas where we could reduce costs or improve our internal systems by switching out an existing tool. We documented everything with the purpose of understanding, systematizing, and optimizing.

Prioritize, prioritize, prioritize.

After we’d had some time to settle in with the new products following the acquisition, we started making plans for how we wanted to improve and grow the existing apps. But we soon realized we’d need to rebuild the apps entirely to create the experience we wanted to.

This meant shuffling our priorities for the platforms for the next several quarters. It wouldn’t have made sense spending time and effort rolling out new features on an old platform that’d be retired soon anyway. We did make a handful of small updates to the existing apps, but those changes were mainly limited to bug fixes and performance improvements to support the platforms for the time being. Small fixes aside, the bulk of our focus shifted to the rebuild.

This meant during the rebuild process we fielded many feature requests by giving a response similar to “we don’t have that yet, but hang tight for the new app!”. We’re grateful to our users who stuck with us during this time as we prioritized the rebuild so we could get it launched as soon as possible.

Consolidate and streamline where possible.

Workify and Growth Geeks have related core functionality. Because they’re so similar, instead of building separate apps like they were previously, we combined the two apps into one. We built the new Workify platform, then created the new Growth Geeks as a market on that platform. It made sense from a business perspective, plus it helped simplify the development process significantly.

We also took the rebuild as an opportunity to do a thorough inventory of the digital services provided through the platforms. Some less popular services were retired and the providers were streamlined. The remaining services were all revamped to better clarify things (like scope of work) for our end customers. Streamlining things where possible resulted in a more concentrated and organized experience for all users.

Be willing to adjust plans along the way.

You know what they say about best-laid plans . . . sometimes things go awry. We had a timeline in mind for relaunching the products, but ultimately that changed as we got further into the rebuild.

There were three main reasons for the delay: first, we underestimated the effort needed to sort through historical data, determine what should and shouldn’t be transferred to the new platform, and actually complete the migration.

Second, we decided to rebrand Workify as part of the rebuild process. It’s important to us that as our users interact with the dashboard, its design and functionality reflect the professionalism they expect from their own brand. Doing a full rebrand added an additional phase to the timeline that we weren’t initially anticipating.

And third, 2020 wasn’t exactly a normal year. We all felt the impact of that year’s events in some way and it affected our business plans too, including our progress with the rebuild.

As these situations unfolded, we tried to stay flexible with our launch timeline. To us, it’s not worth releasing an incomplete product just to meet an ideal deadline. We wanted to take the time to dot our i’s and cross our t’s so we could release a reliable product we felt confident would elevate the experience for our users, not cause them more headaches.

Launching isn’t the end. It’s just the beginning.

Sometime after Workify launched, I remember telling my teammates during one of our weekly retro meetings that it felt like we were now moving into the next era of Workify. It was the end of one phase. Now onto the next.

In a way, the launch almost felt anticlimactic to me. We’d been working toward this launch for two years (almost to the exact day) and, while it was definitely exciting to finally reach it, the feeling wasn’t entirely what I expected.

It wasn’t like running a race — you cross the finish line, hear the cheers, get the medal, and then go home. (I’m no runner, but hey, I’ve got a good imagination.)

A launch is both a finish line and a starting point. It was both “Yay, we did it!” and “Okay, here we really go.” What happens after launching is just as important as the events leading up to it. So you pick up that medal, pat your team on the back, and then keep going.

Beginning the next phase for Workify and Growth Geeks has been a whirlwind. It’s been a rewarding and exciting experience, as well as a chance to hone our team’s skills. We love working on products that help teams and individuals work better together.

If you want to talk with a development team about launching (or re-launching) a SaaS product, we’d love the opportunity to connect with you.

Want to read more tips and insights on working with a web development team that wants to help your organization grow for good? Sign up for our bimonthly newsletter.

By Emily Kassmeier

Project & Marketing Manager

Emily can often be found reading, enjoying the outdoors with her dog, and trying to keep her houseplants alive.