SaaS Thinking: Rearchitect your SaaS platform (FrontEnd side)

What is & Why SaaS?

SaaS stands for Software as a Service, is a cloud-based or partially cloud-based computer program that is constantly being added to, improved, and maintained and that users pay for on an ongoing basis.

SaaS providers host a software application and make it accessible to clients on any internet-enabled device. They also provide IT support and network security. Today, an increasing number of business apps are built this way.

For businesses, using the services of a SaaS company rather than installing software locally brings a host of advantages — from scalability and mobility, to low-cost updates and easily accessible IT expertise.

In this article, I will share my experience in SaaS and how we re-architect our old SaaS platforms to be smart SaaS from the Front-end side.

Before I start with our approach, let me give you a brief about our current solution to focus on the problems and challenges that we face and how we think of solving it.

Currently, we have 3 platforms:

ATS platform (Applicant tracking system — HR Software) including mobile App.
Video Assessment/Interview platform.
Onboarding platform.

All these platforms are Multi-tenancy based, work independently and there is an integration between each other.

The challenges:

Each one has its own tech stack from the backend that used TCL, Php Phalcon or Php Laravel and Variety in JS frameworks like React, Angular, Vuejs & JQuery.
Each one has its own Design guideline and User experience.
Hard to integrate with external systems.
Each one has its own deployment strategy.
One platform uses SVN and others use Git flow as version control.
One of them follows Monolithic architecture.
Can’t switch the developers between platforms as a different stack.
Steep learning curve.

Vision, Mission & Goals:

The main purpose of this architecture is to unify the front-end technology from javascript framework, CSS framework & design guideline across all platforms, and as per our focus now on the front-end side so we will cover just this area.

The important point here is that we are planning for multi-tenant cross platforms, which means all platforms will serve the same look and feel & design guidelines but different businesses, different menuing and the platforms work with each other or can work independently.

We agreed that our approach is API first, monolithic to microservices to increase the scale of operation, accelerating the pace of change, escaping the high cost of change & delivering value faster.

And the API first approach helps us to integrate internally or externally in an easy and fast way, such as internal platforms or external like SAP, Oracle,… and without forgetting the mobile side.

Last point about API first, that we can work on different backend tech stacks if needed.

The Plan:

Understand our current system and create statistics for the main components that we used.
Understand each component’s variety and parametrize it from functionality and design sides.
Choose the best Javascript framework.
Choose a proper Design guideline & CSS framework.
Collect all other components/plugins that need to be in the platform (Cross-Cutting components).
The strategy of shared components & CSS framework across all platforms and take the benefits of git-flow and CI/CD for building & deployment.

So I will go deep for each point in the plan, Let’s get started:

(1) Understand our current system and create statistics for the main components that we used

Why?

This will make it easy to understand the main components that we used, to help us create very dynamic & centralized components.

and help us make the decision of choosing the best CSS framework that covers most of our needs.

How?

We started to collect all pages across all platforms and categorize them into components, here is a sample of the sheet how it looks like:

The statistics across all platforms:

As you can see from the above chart we have 10 main components that serve in our systems, which means if we collect all features from each component and make sure that they support all needs so we can guarantee that we can create any page very fast.

(2) Understand each component’s variety and parametrize it from design and functionality

Actually, we dig deep into each main component to extract all features that we need to be valid across all pages, so here is a summary for each one:

Dynamic form fields (30%).
Data Listing — Table & Card (28%).
Charts (10%).
Data Listing with cluster (10%).
Profile (6%).
Custom (4%).
Custom Widgets (4%).
Content (8%).

So these are the main components which means if we build each component to be configurable and cover all variety as per each page/business so we are done with more than 70% of any platform and we can focus on the main business which is the 30%.

And I believe this approach should be applied to all business types and platforms and especially those who is SaaS-Based

(3) Choose the best Javascript framework

We did research before to choose the best javascript framework:

Angular vs Vue vs React

Angular

Vue

React

The Winner is VueJS

Vuejs

Actually we have a good experience in Vuejs (CDN & SPA) especially with the latest platform for assessment and we used SPA and CDN in the ATS platform but we did the comparison to make sure that we did the right choice and make sure that Vue covered all needs especially with new architecture, and Here are the following reasons why we chose it:

Support SPA and SSR.
Simple routing.
Reusable components.
Dynamic UI binding.
Easy to learn and lately easy to find Vuejs developer.
High performance.
Too many UI libraries can integrate.
Support ES6 and Typescript.

(4) Choose a proper Design guideline & CSS framework

This is the tough part of research as we couldn’t afford any missteps along the way and the framework should cover all of our needs, I will list all of what we need before choosing the framework:

Amount of time required to code.
Too many helpers classes and styles.
Easy to update the theme guideline.
We chose Vue so we preferred a framework that supports Vuejs.
The framework that supports our main components.
Maintenance of code.
Support for the future.
Server-side rendering.
Support for mobile development and mainly PWA.
Support cross browsers.
Support RTL direction as the platforms will support multilingual languages like Arabic.
Rich components.
Accessibility.
Performance and productivity.
Support sketch app style guide/Library to help the designers and product manager create UI in an easy and fast way.

So we collect the best frameworks that may fit our needs and here is the comparison sheet:

The winner is Vuetify

Vuetify

What about the Design Guideline?

There are plenty of design guidelines such as Bootstrap, Google material, Ant, Lightning, IBM, IOS,…

We decided to go with Google material design and I know this should be part of the CSS framework but I want to mention it here to know we decided on Google material so because Google has developed Material Design as the culmination of their experience and knowledge in digital experience design — They have made the mistakes so we don’t have to, which means we can save a lot of time because we don’t need to develop our own visual language and we can sidestep common design pitfalls.

Another point is that our users subconsciously attribute a level of trust and security to our app beyond its station because they will associate our app with Google.

What about identity?

We didn’t lose it as we will do small touches to add our identity without affecting the core of UI/UX Material.

(5) Collect all others components/plugins & helpers that need to be in the platform

i18n & textual updates
ACL / RBAC / ABAC
Notifications, Alert & Queued
Dialog & Panel (top, right, bottom, left)
Editor — Wyswyg (UI, Email & PDF)
User Profile
Upload/Import
Image Cropper
Date format — time zone
Emails
Calendar
Header/Drawer
…

(6) Strategy of Shared components & CSS framework across all platforms and take the benefits of git-flow and webpack for building

What is this?

While we have multi-platforms, which work independently and all of it will serve the same frameworks, shared configurations & settings and the shared components and for sure different routing, we should think about how will can communicate between each other from front end perspective, deployment strategy, get latest from the shared components and to make sure all platforms working in the same spirit.

Options:

1. One Repository, One build:

Which means one repo that holds everything from shared components and the css framework, so the router will include all links and the pages will be for all despite for platform type and the build will create a single dist.

2. One Repository, Multi build:

Which means one repo that holds the shared components folder including the css framework and creates a folder for each platform with an entry point so each one has their own router and custom components but use the shared component and css framework and we should build a dist for each platform.

3. Multi Repositories:

Which means create a repository for each platform and it will use the shared component and css framework as external plugins.

I summarized each option with list for the main practice, check table below:

And the best approach that fits our need is the third one “Multi Repository.

So one repo for each platform will be decoupling, standalone deployment, easy to access the routing and you have your own git-flow & CI/CD, strict to use the shared component and finally more organized.

I know this topic needs a lot of details to cover each point but i tried as much as I can to cover the idea in general and in the future will share more details if you like it.

There are two parts we will cover it later as separate articles:

How to think about SaaS as UX designer.
Describe deeply about the front-end structure from multi-repository, build process, use the sharing components and how the platforms will interact with each other.