5 ms·

I'd say it's even simpler: Software as a Service is a lot easier to develop than software that a third party has to install: Integration of build pipelines that

I'd say it's even simpler: Software as a Service is a lot easier to develop than software that a third party has to install: Integration of build pipelines that deploy the software immediately are a blessing for bugfixing and you can build an insane backend out of third party dependencies noone but you has to ever install and connect to each other. I don't like the privacy problems this generates, but in a business environment I want my stuff to work for my customers, and that means I do the hosting.

MarkMc 7y ago
Keep in mind that it's possible to develop Software as a Service by selling software that the user has to install - we have done it with our accounting software Solar Accounts. This approach is probably more painful to develop than the traditional web app, but it does give our users features such as (a) end-to-end security and (b) storing data locally - which are selling points for some users.
rakoo 7y ago
There is also the huge advantage of not having to install anything. It's already hard enough to convince my friends to switch to any open source videoconferencing in-browser solution, I would never go through having them install a whole application. "No install" is a major selling point, unfortunately.
- Silhouette 7y ago
  "No install" is a major selling point, unfortunately. I'm not sure that's entirely true, but since most people are now familiar with the likes of mobile app stores or one-click/one-command installations that Just Work(TM), the insane complication and risk that come with trying to install and manage software on a major desktop platform like Windows is now obvious for all to see.
  - cosmie 7y ago
    It depends heavily on the market. For B2B products, it's a huge win for driving market penetration on otherwise locked-down work computers. While development and IT sometimes get exceptions easily, the majority of business users have pretty locked down machines with minimal flexibility in installing software. For consumer markets, you're right that it may not be as big of a factor, other than user expectations on the Just Works(TM) model from app stores.
    - Silhouette 7y ago
      The other side of your B2B scenario, though, is that a lot of places won't be allowed to use unofficial SaaS anyway, because of regulatory and legal concerns, corporate spending authorities, etc. If you can get your desktop software selected as the standard across a large organisation, that's a very nice win.
      - cosmie 7y ago
        I agree that becoming the official software across a large organization is a huge win. It makes your solution the path of least resistance internally. But as far as using unapproved SaaS, they won't officially allow you to. But it does change the power dynamics at play considerably, since it's a matter of compliance rather than capability. An unofficial piece of desktop software is a non-starter, since simply installing it would require notification to and the assistance of IT for the majority of corporate workers that don't have the proper privileges to install it. An unofficial SaaS, however, can easily fly under the radar of regulatory and legal compliance teams, either via free tiers that don't require payment or via small enough T&E expenses that they never get noticed above the user's immediate reporting chain. This puts a soft limit on the amount of friction and red tape that IT and legal teams can put onto business users, because if you make it too hard for them to get the tools they need to do their job, they'll just go around you. That leads to a lot of interesting dynamics. - My current company uses Skype and Microsoft Teams for internal communication, but the way it's configured makes it super unreliable. IT has repeatedly expressed that the issues are user error, and not their problem. So we have entire offices and divisions that use unofficial Slack communities, some paid and expensed and some free. And it's already so embedded in various workflows (including client facing ones) that IT can't rote block it. It's now forcing our IT team to evaluate Slack as an official vendor, because we're using it anyway and they have no insight into usage (which leads to those regulatory and legal concerns you mentioned). - My current company uses Exchange for email, but routes everything through Google for spam quarantine services. Our company email is a registered GSuite account, but every service (except the automated quarantine) is disabled because they don't want us using the other products. The division I work for does client consulting, and I need access to Google Ads, Google Analytics, and Google Docs (when a client dictates) to do my job. And many clients don't want to give access to personal GMail accounts. The solution? The account team that was most impacted is paying for and expensing an entire second, unofficial GSuite account on a random corporate subdomain they already had set up. IT even nudged me to that account team when I raised a stink about access needs. Turns out over 25% of the company is using that shadow GSuite account, and we're beholden to the good graces and P&L of the account team that's currently eating that cost. - It's hard to police this. Even if you try to implement internal controls on the financial to catch these sorts of things, there are always ways around those. For example, I've seen plenty of clients leverage several of our existing agency retainers or contracts to have us acquire solutions on their behalf (which we use on their behalf, but also expand access to them) and just bill it as a passthrough cost against the existing spending authority. This would be a non-starter for desktop apps, but works really successfully for SaaS.
archagon 7y ago
SAAS and the goals outlined in this article can be perfectly complementary if you let client-side JS do most of the work. Just because an app runs in the browser doesn’t mean that you also have to share all your data with the developer, or lose your ownership of it.

MarkMc 7y ago

Keep in mind that it's possible to develop Software as a Service by selling software that the user has to install - we have done it with our accounting software Solar Accounts. This approach is probably more painful to develop than the traditional web app, but it does give our users features such as (a) end-to-end security and (b) storing data locally - which are selling points for some users.

rakoo 7y ago

There is also the huge advantage of not having to install anything. It's already hard enough to convince my friends to switch to any open source videoconferencing in-browser solution, I would never go through having them install a whole application. "No install" is a major selling point, unfortunately.

Silhouette 7y ago
"No install" is a major selling point, unfortunately. I'm not sure that's entirely true, but since most people are now familiar with the likes of mobile app stores or one-click/one-command installations that Just Work(TM), the insane complication and risk that come with trying to install and manage software on a major desktop platform like Windows is now obvious for all to see.
- cosmie 7y ago
  It depends heavily on the market. For B2B products, it's a huge win for driving market penetration on otherwise locked-down work computers. While development and IT sometimes get exceptions easily, the majority of business users have pretty locked down machines with minimal flexibility in installing software. For consumer markets, you're right that it may not be as big of a factor, other than user expectations on the Just Works(TM) model from app stores.
  - Silhouette 7y ago
    The other side of your B2B scenario, though, is that a lot of places won't be allowed to use unofficial SaaS anyway, because of regulatory and legal concerns, corporate spending authorities, etc. If you can get your desktop software selected as the standard across a large organisation, that's a very nice win.
    - cosmie 7y ago
      I agree that becoming the official software across a large organization is a huge win. It makes your solution the path of least resistance internally. But as far as using unapproved SaaS, they won't officially allow you to. But it does change the power dynamics at play considerably, since it's a matter of compliance rather than capability. An unofficial piece of desktop software is a non-starter, since simply installing it would require notification to and the assistance of IT for the majority of corporate workers that don't have the proper privileges to install it. An unofficial SaaS, however, can easily fly under the radar of regulatory and legal compliance teams, either via free tiers that don't require payment or via small enough T&E expenses that they never get noticed above the user's immediate reporting chain. This puts a soft limit on the amount of friction and red tape that IT and legal teams can put onto business users, because if you make it too hard for them to get the tools they need to do their job, they'll just go around you. That leads to a lot of interesting dynamics. - My current company uses Skype and Microsoft Teams for internal communication, but the way it's configured makes it super unreliable. IT has repeatedly expressed that the issues are user error, and not their problem. So we have entire offices and divisions that use unofficial Slack communities, some paid and expensed and some free. And it's already so embedded in various workflows (including client facing ones) that IT can't rote block it. It's now forcing our IT team to evaluate Slack as an official vendor, because we're using it anyway and they have no insight into usage (which leads to those regulatory and legal concerns you mentioned). - My current company uses Exchange for email, but routes everything through Google for spam quarantine services. Our company email is a registered GSuite account, but every service (except the automated quarantine) is disabled because they don't want us using the other products. The division I work for does client consulting, and I need access to Google Ads, Google Analytics, and Google Docs (when a client dictates) to do my job. And many clients don't want to give access to personal GMail accounts. The solution? The account team that was most impacted is paying for and expensing an entire second, unofficial GSuite account on a random corporate subdomain they already had set up. IT even nudged me to that account team when I raised a stink about access needs. Turns out over 25% of the company is using that shadow GSuite account, and we're beholden to the good graces and P&L of the account team that's currently eating that cost. - It's hard to police this. Even if you try to implement internal controls on the financial to catch these sorts of things, there are always ways around those. For example, I've seen plenty of clients leverage several of our existing agency retainers or contracts to have us acquire solutions on their behalf (which we use on their behalf, but also expand access to them) and just bill it as a passthrough cost against the existing spending authority. This would be a non-starter for desktop apps, but works really successfully for SaaS.

archagon 7y ago

SAAS and the goals outlined in this article can be perfectly complementary if you let client-side JS do most of the work. Just because an app runs in the browser doesn’t mean that you also have to share all your data with the developer, or lose your ownership of it.