How does this affect the development process?

In theory, the development process for building a SaaS app is rather similar to any other type of application, but in practice, there are nuances and considerations that you must note as a developer working on a SaaS project.

Release often, release early

There is no “annual release cycle” for a SaaS app. The expectation is that functionality will be broken down into manageable slices, developed, and then pushed out as soon as they are ready. This requires a bit of a mindset shift if coming from a more traditional release cycle. All changes have to be incremental, generally contained to a small part of the applications, and ready for release ASAP.

This mindset of getting the code into the hands of the users will have to be backed up by automated pipelines that build and release the new code without much manual intervention.

While it is possible to roll out the updates to sections of the audience to make sure there is nothing catastrophic in there, it is much more typical for a small-to-medium-sized SaaS application to simply push the updates out to all of the users all at once. For this to be successful…

Testing, testing, testing

If the code is released to the entire user base in one go, and often with no real way of rolling back the change, you had better hope that it works!

The only way to build any sort of trust that the code will operate as advertised is to test it, and in a “release often, release early” mindset, this means automated testing. While this doesn’t necessarily mean adhering to a TDD mentality, this can certainly be useful.

You’d better be full stack

Okay—this is not absolutely required. I’m sure that the larger SaaS applications are worked on by specialists in the database/backend/frontend disciplines. But it will certainly help to have a good knowledge across the different application layers.

The way that SaaS applications “grow” in an almost organic way through the fast cycles and near-instant releases means an understanding at least across the layers, and an understanding of how a decision in the database may affect the frontend is invaluable.

Know thy user

While this may not be required for each developer in the team, it is absolutely essential that the team as a whole understands who is using its product, why they are using it, and where the value is. This knowledge and understanding will come from assessing the analytics and also from “softer” approaches, such as focus groups and interviews with users.

This understanding should flow down into the development process through user stories. From the developers’ point of view, this may manifest in seemingly sudden shifts in direction, if a particular feature has not landed well with a focus group or user interviews have shown that a particular path is the wrong one. The ability to pivot quickly is important across the team.