I have long wanted to talk about the difference between creating SaaS (online) services for small and medium-sized businesses from creating classic automation systems for the same business segment, which, in fact, I will start doing today. In my terminology, a classic solution is a desktop platform solution that implements one or another functionality for SMB and can be customized to the needs of the client.
Factors affecting development.
Instead of a preamble, I will look at the creation of a new service in terms of the price of the issue / the necessary resources and their savings.
In the case of SaaS, startup teams usually have:
a) limited budgets;
b) understanding how and for whom to make a service – full house functionality of the solution, classification of the automation system or application area standard, i.e. some classical understanding of the rules for creating an application;
c) time and other restrictions – the team is forced to start selling quickly and not always the product corresponding to the completed Roadmap;
Each item affects the process, timing, quality of development as a whole. All restrictions are caused by the task itself and are constant, except for non-financial restrictions (point “b”). In my opinion, when creating SaaS services, it is necessary to look more freely at the classical requirements for the development process, thus optimizing the rest of the constant costly parts of the project without visible changes in the quality of the task being solved. Those. it is not necessary to apply the postulates that worked earlier when creating classical automation systems when creating SaaS services.
Simplify services without risking results.
The first is to make not features, but simple vertical solutions, not even vertical ones, but covering the needs of the work of a department, a group in a company, a distributed group. In this case, the main thing is to guess where to make efforts – what to automate. For example, at the beginning of the SaaS era, Vasily Shabat created a travel accounting service and only then realized that the service is in demand by large companies, does not sell itself, requires efforts to integrate with accounting systems and has already been implemented by many conservative players.
Cloud Services Example: Columbus Logistics Department My Warehouse
The classic approach: more functionality – do everything to the maximum, in the hope that suddenly someone will need the 1053rd necessary function.
The second is to follow the path of “cutting off unnecessary functionality”. What I mean by this is not following standards, for example, ITIL and “cutting off” a large layer of solution functionality, for example, access rights. From the successful examples of the latest ASANA, the philosophy of the creators of which is that in a small group of employees the administration of access rights is generally not necessary – all 10 pairs of eyes understand that they are in an excellent team of like-minded people and there is nothing to hide from each other, and the manager perfectly sees , what the subordinate does in the “open” service space and in the office 5 by 5 meters.
Classic approach: Servis Desk is ITIL, Pink Elephant, but why is it a team of 10 people?
The third is to try to combine simple products into bundles that don’t exist yet, or start developing a huge Shuttle with such a non-standard combination – a bundle just might turn out to be successful. But don’t experiment with Unified communications – that’s enough.
Cloud service examples: Quickme SMEOn
Classic approach: CRM framework or HRM or Docflow + consulting + training + changing the mindset of the company… what is SaaS for? SaaS is designed to save!
There are chances (instead of conclusions).
I have not yet tried to talk about the technological creation of SaaS applications, which in itself is cheaper (multi-tenancy, for example) and focused on ideological things that will help simplify and reduce the cost of the creation process. It turned out that the first approach is a clear savings when hitting the target. The second approach is to optimize development costs due to the uselessness of part of the SMB functionality. The third is the search for your path and positioning. Thus, to bring success closer, do a simple service – applicable by three employees of the company, leave everything superfluous and go with one suitcase, which will contain one shirt – the solution to the client’s problem. Well, combine classics and Casual in approaches, if not scary.
! It is important that SaaS application developers have a unique opportunity to experiment – to simplify their services and create a new philosophy of automation.
In the first part of the article, I talked about ways to optimize the cost / functionality when creating SaaS (Online) services. My approach to the problem was rather strategic (where to run, what to cut off), but not technological, and I had to start somewhere. What came out of it can be read here.
Today, as promised, I have guests who openly share their recipes for creating successful SaaS stories. I note that most of the invited companies have already taken place in terms of business and are leaders in their automation segments (gurus). Projects have also come that are just starting to win the hearts of users by leaps and bounds (beginners). Visitors today: amoCRM, MySlad, Asoft CRM, Сopiny, Do.Docs, Zingaya, SMEOn and I asked everyone the same questions that will help replicate the experience of colleagues and transfer it to new teams. In my opinion, it turned out to be an interesting mix of opinions that will help all those who decide or have already decided to play in this field to approach the creation of SaaS in the right way.
1. Yes, the idea is banal – they did it rather because they could, and not because they wanted exactly this from a variety of options
2. LAMP + stuff because the whole team worked on it.
3. We call it small working groups. These are sales departments from 3 to 20 people, which can be in both SMB and Enterprise. Our key customer is the head of the sales department.
4. I do not strongly believe that there are magic pills that can reduce development costs. A good specialist will kill any bad one, even if the latter is provided with the best tools. In addition, good management and processes will improve development by an order of magnitude more than any toolkit. Therefore, in fact, all development issues are team issues.