Our approach to product rewrites

This piece is inspired by an insightful post on software rewrites. Phorest is 14 years into its mission of helping salons to grow their business. We have seen industries shift, new technologies emerge and competitors try to copy us. We have had to rebuild our product on multiple occasions. We’ll look at various approaches to these rewrites, Phorest’s approach, and how they have played out, either successfully or failing.

How companies have approached it

📝Basecamp — start from scratch but not sunsetting — success

☠ Netscape — started again from scratch — failure

⌨️Gmail -> Inbox — two apps with the same backend — failure

💸FreshBooks & BillSpring — stealth rewrite — expensive success

💇‍♀️Phorest M6 -> M7 -> Web—incremental — long term success

We believe there’s another approach to a rewrite and have proven it works in our SAAS vertical, we’ve been able to keep innovating and upgrading our system without letting newcomers eat our lunch by incrementally changing our product screen by screen.

Early days — Memento 6

We started off in 2006 by building a basic appointment screen which was connected to our SMS engine. It was built in Delphi and on-premise. As we got product market fit we focused on building out hair and beauty specific functionality. We called it Memento 6, even though it was version 1 because we wanted to be more credible to potential customers :)

Moving to cloud — Memento 7

The Memento 6 application was quite problematic, we needed to rebuild and move to the cloud for many reasons:

• It was built when we were in startup mode, so the quality was not up to best standards
• The language and framework was very old and people didn’t want to work on it
• As it was on-premise customers could lose their data if they weren’t backing up their systems or their pc crashed.
• Services like AWS were opening up opportunities for SAAS businesses to adopt cloud computing and the other industries were trending this way
• We wanted to capture digital bookings — not possible with on-prem databases
• Logging in remotely to troubleshoot and update customers databases was extremely difficult to manage and caused alot of support overhead

Our product is relied by upon by thousands of people to do their job, drastic changes to the visual design and information architecture would have resulted in revolt. When building the UI layer for the new cloud backend we made a very conscious effort to keep it the same.

We hired a dedicated team to work on Memento 7, while putting Memento 6 in maintenance mode. That team created a cloud backend, replicating all existing functionality, creating a hosted infrastructure on AWS and solving some distributed system challenges — for example what happens when an appointment changes on one GUI or on the backend.

When functionality was complete for Memento 7, all new customers were by default on this product. We then built an export / import tool which would migrate customers from memento 6 to memento 7.

Memento 7 — rework

Memento 7 had two big overhauls in its time.

1. A look and feel facelift — screen by screen initiative to modernise the product, this was because we copied the look and feel from memento 6 to reduce the friction of change.
2. An infrastructure overhaul to resolve growth pains due to the traction of the product — more details of that here.

Phorest Web (not Memento 8)

Memento 7 was written in Java Swing, which is a 23 year old UI toolkit for building applications which has been deprecated for many years. It’s a native client that is installed on our customers PCs.

We strive to give our customers the best tools to retain customers and grow their business. As we grew past 4,000 customers we saw the release frequency and friction of upgrades was limiting the speed at which we could make changes, improvements or experiments with the system.

Swing was holding us back, it didn’t enable us to deliver on our engineering endeavours, everything was custom built and that’s extremely slow and expensive to deliver. Engineers became very frustrated working with the technology

Phorest Web is the future of our platform:

• We can leverage other SAAS products to improve ours
• Use open-source libraries and frameworks
• Adopt best in class technologies and modern software development practices
• We can make our interface more responsive and intuitive
• The ability to ship fixes, improvements, features and experiments without having to push new installers

We are in the fortunate position that our backend has stood the test of time, our past scaling work and continuous improvements have meant we don’t need to do a big overhaul.

Our approach

Having learned from our past experience on rewrites, it’s very important for our web move that we make gradual, incremental changes — not disturbing users in one big bang. In order to achieve that goal, there have been some instrumentally important parts to our web rebuild approach.

Embedded web browser

We achieve this by embedding a chromium web view inside of our native Swing application. Allowing us to embed new features and panels into the swing app. We use a powerful tool called Jxbrowser to achieve this.

Feature flags

We leverage feature flags and their ability to allow us to quickly iterate on features, safely release features to customers, quickly preview work in progress and to allow non technical people to take responsibility for when customers see new features.

Controlling the navigation

Jxbrowser gives us the capability to interact with the DOM and for the DOM to interact back with Swing. So for example you can set some values in the web application or even get the web application to call some functionality back in the Swing app.

This is extremely powerful for us because we are able to navigate from web screens back to older Swing ones, giving us a controlled experience (like above). This approach allowed us to pick the prioritise differently, so we can solve specific problems rather than in smaller batches, ship, learn and iterate — like in the example above we were able to keep our older reports.

Common problems with scaling product

There are two commons challenges we see products facing as it grows in usage and functionality.

1. The quality of the system decays and engineers push for a rewrite because they can’t work with it anymore.
2. The frameworks age and become deprecated, unmaintained and stagnant.

Inevitably this will come up in Phorest, but my goal is to prolong that conversation for as long as possible :)

We’ll do this with a high bar for technical standards, having a high bar for the people that join our team, a shared set of values and guiding principles of how we build product. Missionaries (not mercenaries) — who care about their craft and the quality of the system that they build. People who value SOLID principles, scalability and reusability.

We also choose technologies that can stand the test of time — not the shiny new trend. Our web framework of choice is Ember.js, it’s built for ambitious projects, has an amazing community and designed for ambitious long-term projects. Engineers working with these types of technologies, who value best practices and have a continuous improvement mindset will be our approach to not having to build a Phorest Web 2 in a few years.

Closing off

We’ve been able to innovate and deliver new functionality as part of our rebuild that has delighted our users. Shipping in small iterations to learn and reduce friction of a change for our end users, these are big advantages of not stopping for a massive rewrite.

If you have any questions, insights or thought — please comment below or reach out to me john@phorest.com :)