Live data from Hacker News

Our Recurring Payment Pricing Was Rejected

jerviswhitley.com

61–70 of 81 posts

Re: Our Recurring Payment Pricing Was Rejected

#61
post #56

I'd like to offer my opinion as someone who LOATHES the SaaS model. The first and only thing you need to consider is who you're selling to (power systems engineering businesses, as you said) and what they do. They make power systems that need to be reliable and last for fifty years or more. You probably know banks use 30 year old COBOL software to make the world tick. Why? Because it's reliable and rarely breaks. Whe…

This is a valid argument. SaaS is a step in the wrong direction for use cases where continued access to the service is crucial. I do not trust LastPass or similar third party systems with my passwords. Passwords are too important a part of my identity that I should have complete and exclusive control over it. (I use a mix of Text files+TrueCrypt+Timemachine and Dropbox for sync). Same goes for email. I use IMAP to ke…

>my email address is still owned by a third party (Google) and they can lock me out of my identity any time

They can lock you out of your past emails, but they can't take your identity away if you use Google Apps for custom domains or MSN Live Domains. You'll still have access to your email address which would probably be "me@firstlastname.com" or something. Actually, if you make it a habit to schedule a weekly outlook download of your emails I don't think they can even lock you out of your email. I've taken steps to do the first part but I'm being lazy and not downloading all my mails onto my computer yet. [Effort vs. Payoff doesn't seem worth it yet]

Re: Our Recurring Payment Pricing Was Rejected

#62
post #15

We get IP ownership, but we don’t bill for our time at all. Instead they become our first customer to use the new tool for a lower yearly fee (including maintenance). You're taking on market and execution risk here, for which you are not receiving compensation. (Presumably you set your consulting rates high enough such that engagements are a win for you. The SaaSification option is at a discount to your rate, which y…

Agreed. I've worked at a company that owned the IP to a CRM-type system fully bought and paid for by a major car maker. The car maker paid my employer millions to develop the system over several years, and then willingly gave up the IP for it at the end of the process.

My employer was then able to go and sell other similar businesses on the same software. It's surprising, but common.

Re: Our Recurring Payment Pricing Was Rejected

#63

This seems especially difficult for a web-based model, and I've personally questioned why anyone would want SaaS when: 1. The company already pays for and supports infrastructure. 2. The company already has a development/IT department that can support an installed product. 3. Viable Open Source alternatives (often using open standards) exist and can be tailored specifically to the company's business needs, either by…

Sometimes the IT department has more important things to work on. If the company makes "widgets", then it's usually better for their IT department to be working on something to make their widget making more competitive (faster, cheaper, better, whatever). So they "outsource" payroll, other HR and whatever else doesn't directly benefit "widget" making.

Re: Our Recurring Payment Pricing Was Rejected

#64

I'd like to offer my opinion as someone who LOATHES the SaaS model. The first and only thing you need to consider is who you're selling to (power systems engineering businesses, as you said) and what they do. They make power systems that need to be reliable and last for fifty years or more. You probably know banks use 30 year old COBOL software to make the world tick. Why? Because it's reliable and rarely breaks. Whe…

>Same goes for power and manufacturing industries, they have old control systems that rarely break, because failures are very expensive.

Out of curiosity, how much experience do you have selling to the manufacturing industry? I have no problems drumming up interest for my sales and marketing SaaS product for manufacturing industry. If you found otherwise we should compare notes.

Re: Our Recurring Payment Pricing Was Rejected

#65
post #50
post #42

Earlier quoted context omitted.

Cars degraded over time, software does not. Get in a 10 year old car and it isnt as good as it was 10 years ago. Its loose and worn. Fire up 10 year old software and its as good as the day you bought it. Yeas the market would have changed around both, but if I have both a car and a piece of software in my hand, as it were, I can see the difference. There for leasing something the clearly degrades makes sense. Leasing…

Software does indeed degrade over time - platform support (gee, do your Windows 3.1 apps run?), security flaws, etc.

It's true for software that's completely standalone, a virtual island. But very little useful software qualifies. Most software interacts with other components, whether hardware, operating systems, external formats, etc., and when those change over time, the software effectively becomes worse, even though it's technically the same as it was before.

Re: Our Recurring Payment Pricing Was Rejected

#66

I'd like to offer my opinion as someone who LOATHES the SaaS model. The first and only thing you need to consider is who you're selling to (power systems engineering businesses, as you said) and what they do. They make power systems that need to be reliable and last for fifty years or more. You probably know banks use 30 year old COBOL software to make the world tick. Why? Because it's reliable and rarely breaks. Whe…

Would your position on vendor stability be mitigated if the SAAS was implemented as an appliance that can be imaged, which is placed under software escrow? If the vendor goes out of business, then you know that you will receive a discrete snapshot of what delivered the service (from the appliance, and the image can be dropped into a VM in your infrastructure), and you would receive all the code that the vendor created to implement the appliance.

You are no worse off than buying off the shelf software from closed-source companies, even large ones like Microsoft/IBM/Oracle that can be counted upon to be around in ten years. I see clients of mine get stranded by those companies all the time on just old versions of products that simply go out of support. In fact, if you get the appliance and the developed source code, you're in a better position because at least then you have the option to explore the feasibility of modifying the code to make it continue to work for your needs.

Re: Our Recurring Payment Pricing Was Rejected

#68

I'd like to offer my opinion as someone who LOATHES the SaaS model. The first and only thing you need to consider is who you're selling to (power systems engineering businesses, as you said) and what they do. They make power systems that need to be reliable and last for fifty years or more. You probably know banks use 30 year old COBOL software to make the world tick. Why? Because it's reliable and rarely breaks. Whe…

Would your position on vendor stability be mitigated if the SAAS was implemented as an appliance that can be imaged, which is placed under software escrow? If the vendor goes out of business, then you know that you will receive a discrete snapshot of what delivered the service (from the appliance, and the image can be dropped into a VM in your infrastructure), and you would receive all the code that the vendor create…

The reason those companies are still running the old versions is because even if they're out of support, they're known quantities. Implementing new versions will require development and testing to put in to place along with the possibility of additional upgrades (OS, other apps/libraries, etc.). Unless you have resources to handle that aspect in addition to any of your actual business, you're going to want to stay on a version for as long as possible instead of being on the upgrade treadmill that Microsoft/IBM/Oracle try to place you on.

Re: Our Recurring Payment Pricing Was Rejected

#69

This seems especially difficult for a web-based model, and I've personally questioned why anyone would want SaaS when: 1. The company already pays for and supports infrastructure. 2. The company already has a development/IT department that can support an installed product. 3. Viable Open Source alternatives (often using open standards) exist and can be tailored specifically to the company's business needs, either by…

> I've personally questioned why anyone would want SaaS when: > 1. The company already pays for and supports infrastructure. > 2. The company already has a development/IT department that can support an installed product. Because adopting a SaaS offering instead means the company can greatly reduce the need for (or entirely get rid of) the infrastructure and staff which both cost exponentially more.

Be careful about making this argument - the people whose job you're trying to eliminate might be the people who are making the decision. A better argument, if it applies, is that you offering reduces non-core work, allowing staff and resources to be focused on core work. Any company that has IT staff will likely benefit from continuing to have that staff, just focused more on value-add activities rather than chores.

Re: Our Recurring Payment Pricing Was Rejected

#70

I'd like to offer my opinion as someone who LOATHES the SaaS model. The first and only thing you need to consider is who you're selling to (power systems engineering businesses, as you said) and what they do. They make power systems that need to be reliable and last for fifty years or more. You probably know banks use 30 year old COBOL software to make the world tick. Why? Because it's reliable and rarely breaks. Whe…

Would your position on vendor stability be mitigated if the SAAS was implemented as an appliance that can be imaged, which is placed under software escrow? If the vendor goes out of business, then you know that you will receive a discrete snapshot of what delivered the service (from the appliance, and the image can be dropped into a VM in your infrastructure), and you would receive all the code that the vendor create…

[deleted]
Post reply on HN