The team I am on is responsible for SaaS development. We have a few flagship SaaS products and also some supporting ones. The flagship SaaS products have complex architectures, large technical challenges, and heavy staffing, and they are the focus of our KPIs. But a flagship project cannot stay the flagship forever — projects have life cycles and phases. Being constantly swamped by requirements with no long-term plan is dangerous. Only with both tactics and strategy will you go further. This article is some thinking about the stages of a SaaS development team.

1. The Golden Age - SaaS Is Business Results

Compared with IaaS and PaaS, SaaS is closer to user scenarios and can directly create business value. For example, CRM manages sales; OA handles enterprise collaboration and communication.

Small enterprises focus on their core business and squeeze costs elsewhere. If IT staff can find some low-cost or even free SaaS, that is undoubtedly for the best. It satisfies business needs without any operations cost.

Operational data and external services are an enterprise’s core assets. As an enterprise grows, building its own integrated IT system is an unavoidable path. Various development, deployment, and operational needs and process standards emerge inside the enterprise, and all of them need IT staff to support them.

In fact, whether in development, operations, or business operations, there are always tasks that are highly repetitive, operationally risky, and time-consuming. This is exactly SaaS’s opportunity for growth. We can solidify CI, CD, and CO into SaaS and use software to guarantee reliable, low-cost execution of the processes.

This is the golden age of SaaS. It advocates a tool culture, exporting skills in the form of tools and providing services. SaaS replaces tedious, error-prone manual process operations, raising team efficiency and improving service quality.

Whatever the role, a team that can build SaaS from scratch and provide shared services will be valued.

2. Gradual Decline - The Rise of PaaS Platforms, SaaS as Outsourcing

After the golden age, all kinds of SaaS blossomed everywhere. Because their use scenarios differ, it is hard to give SaaS tools a unified development plan. Data does not flow between one SaaS and another, their processes differ, and barriers form, fragmenting the various IT systems.

In fact, everyone can sense the problem, but when it comes to distributing interests, no agreement can be reached. It needs a higher level to drive it. The solution is nothing more than the old saying: what has long been divided must unite, and what has long been united must divide. We need to build a common platform so that all SaaS has a shared runtime and dependency environment.

Provide hosted SaaS runtime services through aPaaS, aggregate scenario APIs through iPaaS, and build a PaaS platform. The hard part of building a platform is building an ecosystem. Just like developing an operating system, R&D is not the hardest part — the hardest part is getting people to develop applications on it.

From initially helping the team hold the line, to starting to operate a PaaS ecosystem, official SaaS gradually draws to a close. The scenarios of SaaS extend infinitely, while the services of PaaS converge. Official SaaS is meant to attract users and ultimately direct them to the platform to develop on their own. Investing manpower to build PaaS is more valuable.

Building an ecosystem means forming an upstream-and-downstream interest relationship with mutual benefit and win-win. A PaaS platform needs more external SaaS developers to make the ecosystem flourish. External SaaS developers need PaaS to provide more and better shared services to improve their output-to-input ratio. PaaS and external SaaS developers each take what they need, and everyone is happy.

SaaS development at this point looks more like outsourcing: helping developers in the ecosystem fill in scenarios and accompanying external developers as they grow.

3. Slow Climb - Outputting Full-Lifecycle Solution Capability

The official SaaS development team knows the platform best. SaaS is close to users upward and runs through the entire platform downward. This is the advantage of the SaaS development team. Beyond that, the official SaaS team supports requirements across all kinds of scenarios, goes through a product’s complete life cycle, and accumulates rich experience. All of this can be exported to other SaaS developers.

Outputting full-lifecycle solution capability means providing guidance for different stages to teams at different stages of development.

Development models, software architecture, coding standards, personnel training, operations management, team collaboration, tech stacks, toolchains, and so on — everything that appears in a SaaS life cycle can serve as a dimension of guidance.

With that accumulation across all dimensions, you also need to deliver whole-solution output tailored to teams of different sizes, different development capabilities, and different business scenarios. Recording and summarizing the evolution process of SaaS teams is especially important.

In the process of outputting full-lifecycle solutions, the SaaS team’s main goal is not development but exporting experience and accumulating influence. Going further, it can also output a SaaS rating model, move further upstream in the industry, and transform from player to referee.

4. Steady Growth - Low-Code Platforms

Since a platform is the goal of tool teams, the SaaS team might as well build a platform too, going with the flow.

There are two approaches to building a platform. The first is to let SaaS sink down; the second is to discover value and create another middle layer.

SaaS needs a deep understanding of the domain it serves and must export its capabilities to other SaaS, whether as APIs or embedded pages. The more SaaS is willing to integrate, the more it has sunk down, and the more its value is reflected. A SaaS that has sunk down also provides raw material for the second approach.

The SaaS team serves users directly; if the product is not good it can be polished over time, and the most important thing is to respond quickly to user needs. Speed can become the core competitiveness of a SaaS development team. A SaaS team must not only develop quickly but also export that rapid-development capability to other developers.

In the stage of outputting full-lifecycle solution capability, you will have accumulated some practice in rapidly building SaaS. I believe that no matter how good a process or piece of advice is, it is no match for providing a tool. A tool that helps developers build SaaS quickly can be built into a platform.

A more general name for this platform is a low-code platform. A low-code platform lets developers complete complex functional requirements with a small amount of code, greatly raising development efficiency and lowering development costs. The SaaS development team escapes the grip of development requirements and turns to platform accumulation.