This content is incomplete and may be inaccurate, feel free to look around & please check back later for updates.

There are a few things in the SaaS development pipeline that can make a product complex from the beginning. These are the points that a seasoned developer will instantly increase estimates which will sound unreasonable at the time. Infact there’s always a relevant XKCD comic which is shown alongside this section. Amazingly this is actually something AI has made infinitely easier.

Another example I have heard over the years is a thought experiment around building an application that can make coffee. For a non-engineer they will list out the basic steps for example – turn on the machine, grind the beans, compress them, put them in the machine, place a cup in place, press a button. But to a developer it’s infinitely more complex than that, as a computer doesn’t know what a bean is, what a cup is, how much a cup holds, what a liquid is, what volume is. The developer has to create these.

In the SaaS world the complexities typically revolve around globalisation/scale. When the platform or app needs to be in two languages, or when a file is saved in one timezone, and that time has to be accurate in another. Whenever any payments are involved and there’s different currencies. Even if there’s one user who is a European citizen who will be using the product. How many users there will be online all at the same time, and how quickly will they sign up. All of these add complexity.

So the answer (for your startup) is to reduce as many of these as possible. Push them down the pipeline, but it’s important to mention they need to be considered, and when they will be arriving.

What is Horizontal Scaling?

For everyone reading this to learn how a SaaS is built, you would have seen this term mentioned a couple of times. Horizontal scaling refers to the design where if you need to support more users simultaneously, or need something to calculate faster, you can have the application running multiple times alongside eachother so they work concurrently. You can think of horizontal as the servers sitting in a line. If you no longer need to support so many users, remove some servers. This can be achieved dynamically in the cloud in various ways.

The important part to note is most websites are designed this way as they’re simple cases that just need to keep track of the user, but when you have a use case where you need something calculated that may take minutes – such as the video generation – it changes the way the platform is designed underneath so that a process can benefit from this.

Horizontal scaling also exists within a single server by creating threads. An application or parts of an application can run many times simultaneously within the same server – this requires careful consideration to prevent computing the same work more than once, and to prevent conflicts. You also have to take in to account the amount of memory the server has, the speed of the processor, and so on. If you want to keep this all within the same server and it’s struggling, you can make the server more powerful – also called vertical scaling.

It often comes down to complexity and costs. Usually far easier to vertically scale, but then eventually you can’t throw more power at it so you have to horizontally scale.

Notes to be organised…

  • No currencies. The platform would not handle any money, currency conversions, or payments directly. This would all be passed off to a third party as they have the scaled infrastructure and security already. It would also be a monthly subscription service – not a pay-per-service. This further removes the platform from needing to know anything currency – all it needs to know is whether a subscription is paid/valid or not.
  • No translations (but maybe layer). Translations can be handled a few ways, either with a third party translating the page, or more controlled by having consistent labelling and storing the translations in the product itself. The third party method is the easiest, and can be added on later. In-product translations can happen further down the track if a customer requires more accurate results.
  • Simplified infrastructure. There won’t be millions of customers overnight so this will be built as a monolithic application – one development chain, one product. As there’s minimal developers it removes a lot of overheads allowing rapid prototyping. This can have faster hardware thrown at it as the customer base grows, with horizontal scaling coming later to keep costs low.
  • Simplified interface. Using a component library (CSS framework) for the interface allows for a friendly user interface for the customer with a consistent look and feel, without the need for expensive staff at this stage. A huge head start.
  • Shared components. Utilising shared components & functions allows for tremendous time savings. The downside is the same as any shortcut – it’s a cost later on (technical debt). However the aim is to get a product out there fast to solve customers problems. Once the customers are onboard this can be addressed – and often the product will be different/change anyway.
  • 3rd party authentication. Shifting the authentication to a 3rd party (AWS Cognito) removes all of the trickery and functions for auth away, leaving us with just a flag saying whether the user is authenticated or not. Much simpler, moves the encryption and security of logins & passwords away, and also shifts all the “sign in with google” auth workload off of our plate later.
  • Modular. The platform would be split into logical components, each a product in itself. This allows for multiple individuals or teams to work individually on each product without interfering or (merge) conflicting with the others. All API’s would sit in an API product, all videos would be rendered with a video product, communication to and from services such as Google and Facebook would be handled with an IO product, and so on. This has numerous other benefits so I might break this out in to a dedicated explainer or article later.
  • Shared. A hidden product would house shared components and libraries allowing for rapid development across all modules/products through re-use, while also providing a cohesive feel to the entire platform of products.
  • CI/CD. There would be a dedicated development->testing->demo->staging->production chain, to force the non-technical staff to view the platform while catching any bugs on the way through, saving on testing overheads while doubling as a much needed demo platform.
  • Unified Systems. Each underlying system would be loaded in the same way, with the same libraries, with common proven technologies & languages to keep everything consistent and simplified – allowing for rapid scale while keeping costs extremely low.
  • Globalisation. The entire system would have globalisation baked in, as the influx of customers about to be onboarded used multiple languages, currencies, timezones, and data laws.
  • Easy & Flexible UI. The ordering system for the customers in the original MVP was a massive code nightmare – we needed to avoid this by splitting it in to logical steps, using methods that severely reduced development time and technical debt.
  • No AJAX. The UI was to use a standard LAMP stack so everyone could understand it, nothing was hidden, and page loads are baked in meaning no need to keep track of statuses or triggers for refreshes of components. It also removes a layer as no dedicated interface API’s are required.
  • Recurring Tree Structure. Brands could set up their assets, and customers could belong to many brands, with customers also belonging to other customers. The best part was each branch or node on the tree work identically, so complex businesses can be created with very minimal upfront development, also minimising training for staff and customers.
  • Simple Customer Onboarding. This was a tie-in to the existing sales strategy discovered from the years of MVP’s. The sales strategy was to develop a working prototype before visiting the customer, to show the customer it’s already there and done so no complicated onboarding in theory. So a customer (demo) needed to be easy to create on the system rapidly.
  • No-Code. Remove the man-hours and incredibly high costs of custom work, by making the entire process a customer requires doable from within a web based interface without ongoing technical help or development. If a developer is required to do something, then that needs to be accessible within the UI by non-developers.