4 ms·

but how does that work out for a SaaS app? (especially a startup that's always adding in new features?) I mean, one idea is to create sub domains - each runnin

but how does that work out for a SaaS app? (especially a startup that's always adding in new features?) I mean, one idea is to create sub domains - each running a different version of your app...but at that point, you kind of loose control and companies would love to stick to an older version (and you'd have to support an older version).

NeutronBoy 10y ago
The same way that Salesforce does it - allow you to flick a switch and transition to a new interface, or turn on a new feature, or whatever. In terms of remaining on older versions, vendor typically restrict this through SLas - For example, you might only get your Tier 1 SLA response (acknowledgement of a serious issue within 1 hour, for example), if you're on the current version, or the previous version. Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that.
- ohstopitu 10y ago
  Thanks for the reply! > Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that. Won't that just mean they'd not like the rate of progress (say daily updates for bug fixes, weekly updates for minor changes, and monthly updates for major changes), and just leave?
  - NeutronBoy 10y ago
    Ahh, now you're really getting into the world of B2E services! They might just leave - but if it's a core service they need, it's a huge amount of effort to migrate users, data, implement a new system, rewrite all their process and documentation, helpdesk manuals, etc. They generally won't mind with general fixes and updates, but if you're changing existing workflows or features, or adding new capabilities in, they'll probably want control about how they roll that our to their users. Enterprises generally don't sign up to SaaS services through a webform and a manager somewhere punching in their Amex (although it does happen sometimes). There'll be a proper contract, with lawyers, and negotiations, etc. There'll be clauses in the contract that most enterprises don't want and they'll try to negotiate away - for example, under what circumstances can the vendor (you) terminate the service? If the Enterprise has spent heaps of money to move onto your service, they'll want assurances that you can't terminate the contract because you feel like it - and if you do, that they can sue you for damages. As you can see it's definitely a conscious decision that you'll need to make if you want to target these Enterprise customers - it's a big investment, and often (particularly in government or if your service is going to be a core platform) you'll get contracts that commit you to 5+ years of service, but the flipside is that now you've locked in 5+ years of revenue from that customer.
    - grantlmiller 10y ago
      I love this conversation. @ohstopitu thanks for asking great questions & @NeutronBoy thanks for providing great answers.
    - ohstopitu 10y ago
      Thanks so much! I've been working on a side SaaS project which I intend to target primarily to Enterprise customers - where I expect to make money (like how Slack does, but it's nothing to do with Office Communication ofc). I've always been looking for details and generally most companies/devs don't like providing info.
    - deleted 10y ago
      [deleted]
icebraining 10y ago
You could do the same as many OSS projects - offer an up-to-date version and an LTS version, both with clear schedules. If the LTS is stable - nothing except security or crucial bug fixes - hopefully you won't lose much time supporting it.
- brianwawok 10y ago
  The fun is the LTS users will want 95% of the bug fixes and 30% of the features only in the current version. Oh and each customer wants a different 30% of the features. So you need to build them a custom branch or they quit.

NeutronBoy 10y ago

The same way that Salesforce does it - allow you to flick a switch and transition to a new interface, or turn on a new feature, or whatever. In terms of remaining on older versions, vendor typically restrict this through SLas - For example, you might only get your Tier 1 SLA response (acknowledgement of a serious issue within 1 hour, for example), if you're on the current version, or the previous version. Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that.

ohstopitu 10y ago
Thanks for the reply! > Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that. Won't that just mean they'd not like the rate of progress (say daily updates for bug fixes, weekly updates for minor changes, and monthly updates for major changes), and just leave?
- NeutronBoy 10y ago
  Ahh, now you're really getting into the world of B2E services! They might just leave - but if it's a core service they need, it's a huge amount of effort to migrate users, data, implement a new system, rewrite all their process and documentation, helpdesk manuals, etc. They generally won't mind with general fixes and updates, but if you're changing existing workflows or features, or adding new capabilities in, they'll probably want control about how they roll that our to their users. Enterprises generally don't sign up to SaaS services through a webform and a manager somewhere punching in their Amex (although it does happen sometimes). There'll be a proper contract, with lawyers, and negotiations, etc. There'll be clauses in the contract that most enterprises don't want and they'll try to negotiate away - for example, under what circumstances can the vendor (you) terminate the service? If the Enterprise has spent heaps of money to move onto your service, they'll want assurances that you can't terminate the contract because you feel like it - and if you do, that they can sue you for damages. As you can see it's definitely a conscious decision that you'll need to make if you want to target these Enterprise customers - it's a big investment, and often (particularly in government or if your service is going to be a core platform) you'll get contracts that commit you to 5+ years of service, but the flipside is that now you've locked in 5+ years of revenue from that customer.
  - grantlmiller 10y ago
    I love this conversation. @ohstopitu thanks for asking great questions & @NeutronBoy thanks for providing great answers.
  - ohstopitu 10y ago
    Thanks so much! I've been working on a side SaaS project which I intend to target primarily to Enterprise customers - where I expect to make money (like how Slack does, but it's nothing to do with Office Communication ofc). I've always been looking for details and generally most companies/devs don't like providing info.
  - deleted 10y ago
    [deleted]

icebraining 10y ago

You could do the same as many OSS projects - offer an up-to-date version and an LTS version, both with clear schedules. If the LTS is stable - nothing except security or crucial bug fixes - hopefully you won't lose much time supporting it.

brianwawok 10y ago
The fun is the LTS users will want 95% of the bug fixes and 30% of the features only in the current version. Oh and each customer wants a different 30% of the features. So you need to build them a custom branch or they quit.