Why don't developers offer payment in instalments?

[softska]

Plugin Alliance does multiple payment for bundles. ohmforce at one point also did (not sure if they still do)

Not popular to do it for developer probably just cuz the extra cost of handling these crap. Everyone that use paypal end up w that billmelater thing anyway if someone really want to do monthly or via vendor like sweetwater (not that I want to have anything to do w that after reading the horror stories)

[kbaccki]

(I knew when I posted this idea that somebody would disagree with it, for no good reason...)

So you post an idea to get feedback. You know you are going to get it. But are unhappy about getting it?

Yeah, that's a doozy... Thinkin' about sig update here...

[basslinemaster]

I've suggested a system which benefits both parties, the customer and the developer.

debatable

The customer can pay £33 to use the VST for a month. Maybe the next month they can't afford £33, so they can't buy the next month's use.

This is called SaaS, Software as a Service ... or subscription or rental etc... However, it comes with an overhead that is built into the cost of the software. And, it typically doesn't end up with you owning the software. Doing subscription on $100 software is stupid.

LOL yet again... What I have suggested ISN'T called SaaS, and you saying it is doesn't mean it is. That's called a 'strawman argument'. How ridiculous.

Why do you think so many people use credit cards? Because they can afford to buy everything they want up front?

I don't debate the need for the credit process or delayed payment. I'm saying that process already exists.

You didn't bother to read my original post... no point in arguing with strawmen.

If you had even a small clue how financial transactions occurred and are tracked you would realize that mine is far from a strawman. There is a system in place that companies use to manage purchases. Doing things outside those known processes is expensive. However, your proposal is just a rental system by another name. And, the rental paradigm doesn't fit the product space.

Where to begin? You can't even understand what I suggested in my original post. I wouldn't have believed it was possible. My proposal isn't "just a rental system by another name", it is nothing to do with rental.
As for "Doing things outside those known processes is expensive". LOL. What exactly did I propose that is "Doing things outside those known processes"? So somebody paying you £33 for one piece of software that expires after a month, twice, and then paying you £33 for another piece of software that doesn't expire, is expensive? And more expensive than the extra sales you would get?

[basslinemaster]

(I knew when I posted this idea that somebody would disagree with it, for no good reason...)

So you post an idea to get feedback. You know you are going to get it. But are unhappy about getting it?

Yeah, that's a doozy... Thinkin' about sig update here...

Did I say I was unhappy about getting feedback? I said "I knew when I posted this idea that somebody would disagree with it, for no good reason...", and some of you certainly have delivered on that prediction!

[basslinemaster]

Plugin Alliance does multiple payment for bundles. ohmforce at one point also did (not sure if they still do)

Not popular to do it for developer probably just cuz the extra cost of handling these crap. Everyone that use paypal end up w that billmelater thing anyway if someone really want to do monthly or via vendor like sweetwater (not that I want to have anything to do w that after reading the horror stories)

If I could understand what you said, I might agree with you. What does 'w' mean? And as for "just cuz the extra cost of handling these crap" - what precise costs do you mean? Can you give me some estimated figures?

[kbaccki]

I take my previous post back... this one's an even better candidate:

you pay a developer to do it for you in ten minutes

[basslinemaster]

I take my previous post back... this one's an even better candidate:

you pay a developer to do it for you in ten minutes

I wrote that in response to the comment "Who sets up the automation for the different tracking?"

So how difficult do you think that is to set up? What does "different tracking" even mean?

The developer would have two products instead of one.
1) One month expiry version, with ten free bonus points.
2) Non-expiring version, which you can buy for only £33 if you have twenty bonus points.

So those who want to buy the full version for £99 can do so, those who have bought the one month expiry version twice in the past, will have twenty 'points' and can buy the full version for £33, the shopping cart will automatically reduce the price. I take it you all know that that functionality exists in just about all e-commerce packages?

That's it. What 'automation' is needed? WTF? Do any of you have any experience with any e-commerce systems? You do know you can give the customer 'tokens' or 'points' or 'vouchers' of any number, in most e-commerce systems, if they buy product X, or spend X amount? And you do know that the whole point of those 'vouchers' or 'tokens' is to REDEEM them on another product, thus making you another sale? So the means to do this already exists in loads of bog standard e-commerce systems. You don't actually need a developer to set anything up, it's just adding one new item to the store, the one month expiry version.

And this is what's even more incredible - that the likes of kbaccki think they are scoring points over a mere idea, by revealing that they don't even understand how an e-commerce site works.

[beely]

As for "Because it's a lot of hassle for no real benefit to the bottom line.
It would take more resources to implement and administer than would be made up for in extra sales."

Evidence, please? "no real benefit to the bottom line" - so increased sales aren't a benefit?

Have you ever been involved with direct customer support for indie developers? I can tell you, customers can be a right pain in the arse!

Yes, there would be development costs in upgrading the plugins protection mechanisms, and updating the payment and website options, the customer database stuff and whatever else the developer uses, as well has handling additional business admin as different amounts of money are coming in over a time period ("well, the first installment of plugin x payment came in in tax year X, with the remainder in tax year Y - and oh crap, we've got to charge VAT on this purchase as well - where does *that* go? - and all these aditional accountancy implications).

Then you've got all the additional customer support issues eg:

- "Well, I paid for my one month installment, but I was away on holiday for three weeks so I didn't really get to use it, can I get an additional month free or my money back"

- "I've paid for two months, but decided I don't like the product and do not wish to buy it, please refund me"

- "I can't afford to finish the payment now, can you hold on to my money until next year when I can pay it off in full"

- "Why the hell are you charging me to demo your software?"

..and all kinds of wacky scenarios that you or I couldn't think of - like I say, real world customers can be over-the-moon complicated more often than you'd think.

Ok, so, given all these additional costs and implications, how much more desirable does that make my product, and how will that affect my marketing and increase sales?

Ok, well first off, selling to the audio plugin market - *all* plugins are pretty inexpensive already, and a higher priced plugin, let's say the £200 range, generally speaking working professionals don't really bat an eyelid at spending a small amount of money on a useful, professional tool.

So you are really only appealing to the less well-off (and by nature, often the more demanding in terms of customer support - and also potentially more likely to want to resell or transfer their licenses - often multiple times given by some here at KVR!).

How many more sales you make is going to depend upon the appeal of your product - I could *guess* that it wouldn't make much difference and I can't say that for me it would make the difference between making a purchase or not.

In business terms, assuming that appealing to the lowest (financial) class of potential user doesn't affect the market placement of my product, I would want these extra hassles to generate, say, 20% extra sales over and above what I would be already getting. I would *guess* that the practical real-world results would be more in the range of a few percent.

And given that few other developers are pursuing the idea, they have already come to the same conclusions, whether they did it by gut feel or whether they did it by research.

There are other factors as well, but I really think that the bet course of action for an indie developer is to make a great product, and price it accordingly, and stand behind it. Flash sales, group buys, marketing tricks and other things are maybe stuff to try when you hit a slump and want to generate more sales, but they tend to devalue the product - witness many people who refuse ever to buy a product at full price and simply wait until the expected discounts or sales start happening.

It's a complex formula, but I don't think your idea changes it much.

It might work for some products or developers, who like the idea, and perhaps it will generate more sales than I think - but I'm doubtful (no empirical evidence, of course!).

The only change to software payment models in recent times is the move to subscriptions, with the pros/cons that those models have - and they certainly don't suit everybody - not to mention the inevitable subscription fatigue when all of a sudden you realise your paying monthly for hundreds of different things in your life...

[whyterabbyt]

I think this would increase sales by a lot. Say, for example, a company selling a £99 synth gave the option of paying three monthly instalments of £33. They could initially offer you a version that had a one month expiration in the copy protection, so you pay £33, get a copy that will expire in a month's time, pay the second £33, and get a second copy of the VST that expires in another month, and then pay the final £33, and get a copy that never expires. Plenty of developers offer beta versions of programs they are working on, which expire after a set time, so that you have to download the latest version from them, so it isn't difficult to do.
If you couldn't afford to pay after the first month expired you would still have your payment counted in their system, and then maybe in a few month's time you could pay the next £33, and download the second copy which would expire after another month, and then pay the final £33 when you can afford it.

There's nothing in this proposal which would be attractive for a developer unless you can prove your theory that it would increase sales at all (let alone 'a lot') is other than entirely speculative.

What level of experience do you have in the relevant aspects of business (sales, finance, marketing, customer relations etc) which has led you to the conclusion that what is effectively a punctuated finance scheme with additional DRM/finance/administration overheads would ultimately be significantly successful for any software businesses, let alone this fairly small niche?

[basslinemaster]

As for "Because it's a lot of hassle for no real benefit to the bottom line.
It would take more resources to implement and administer than would be made up for in extra sales."

Evidence, please? "no real benefit to the bottom line" - so increased sales aren't a benefit?

Have you ever been involved with direct customer support for indie developers? I can tell you, customers can be a right pain in the arse!

Yes, there would be development costs in upgrading the plugins protection mechanisms, and updating the payment and website options,

See my previous post - you add ONE new item, it takes about three minutes, I do know how to set up e-commerce sites...

the customer database stuff and whatever else the developer uses,

No, no need to change the customer database, I've just explained how it works with tokens/vouchers/points.

as well has handling additional business admin as different amounts of money are coming in over a time period

In what way is this any different than if company X produced a new product that was a third of the price of its current product? This is nonsense.

("well, the first installment of plugin x payment came in in tax year X, with the remainder in tax year Y - and oh crap, we've got to charge VAT on this purchase as well - where does *that* go? - and all these aditional accountancy implications).

What "additional accountancy implications"? If I, for example, sold an album of 12 songs, and then decided to also sell it in three lumps - you buy the first four songs for a third of the price, and so on, what's the big deal? All the accounting is done by your e-commerce package and your accounting package - you aren't manually entering thousands of transactions into it by hand. You're trying to come up with reasons for the sake of it.

Then you've got all the additional customer support issues eg:

- "Well, I paid for my one month installment, but I was away on holiday for three weeks so I didn't really get to use it, can I get an additional month free or my money back"

Simple answer: no.
Or another simple answer: you can limit it 100 hours of use, or 50 hours of use, or 200 hours of use, instead of one month.

- "I've paid for two months, but decided I don't like the product and do not wish to buy it, please refund me"

They weren't buying the full product, they were buying one month of use of it, which they've had, hence the answer is no - and how many people are going to do this anyway? Are you serious? You're clutching at straws here.

- "I can't afford to finish the payment now, can you hold on to my money until next year when I can pay it off in full"

Yes, of course they can. Why would it bother you as a developer?
They aren't "paying off" anything, it isn't a credit agreement.

- "Why the hell are you charging me to demo your software?"

Ridiculous. You are charging them for one month's use, and the all important ten vouchers/points/tokens, towards the reduced cost of the full product.

..and all kinds of wacky scenarios that you or I couldn't think of - like I say, real world customers can be over-the-moon complicated more often than you'd think.

And so what? You deal with them.

Ok, so, given all these additional costs

You haven't shown any additional costs yet, just conjecture.

and implications, how much more desirable does that make my product, and how will that affect my marketing and increase sales?

Ok, well first off, selling to the audio plugin market - *all* plugins are pretty inexpensive already, and a higher priced plugin, let's say the £200 range, generally speaking working professionals don't really bat an eyelid at spending a small amount of money on a useful, professional tool.

WTF? The market isn't just working professionals...

So you are really only appealing to the less well-off (and by nature, often the more demanding in terms of customer support - and also potentially more likely to want to resell or transfer their licenses - often multiple times given by some here at KVR!).

Here we go... I've already proved the number of resales of even the most popular software is less then 8 a year on KVR... See one of my previous posts in another thread.

How many more sales you make is going to depend upon the appeal of your product - I could *guess* that it wouldn't make much difference and I can't say that for me it would make the difference between making a purchase or not.

In business terms, assuming that appealing to the lowest class of potential user doesn't affect the market placement of my product,

Oh, of course! It's bound to! Nobody 'rich' will buy it any more!

I would want these extra hassles

They are all conjecture, and irrelevant.

to generate, say, 20% extra sales over and above what I would be already getting. I would *guess* that the practical real-world results would be more in the range of a few percent.

And given that few other developers are pursuing the idea, they have already come to the same conclusions, whether they did it by gut feel or whether they did it by research.

So they've all thought of this already? Did they ask their customers? Like "Would you buy our product X if we offered three monthly instalments?"

There are other factors as well, but I really think that the bet course of action for an indie developer is to make a great product, and price it accordingly, and stand behind it. Flash sales, group buys, marketing tricks and other things are maybe stuff to try when you hit a slump and want to generate more sales,

And my proposal is none of the above...

but they tend to devalue the product - witness many people who refuse ever to buy a product at full price and simply wait until the expected discounts or sales start happening.

Which are exactly the sort of people who will buy using my proposed method...

It's a complex formula, but I don't think your idea changes it much. People don't do. the only change to software payment models in recent times is the move to subscriptions, with the pros/cons that those models have - and they certainly don't suit everybody - not to mention the inevitable subscription fatigue when all of a sudden you realise your paying monthly for hundreds of different things in your life...

What has that got to do with my proposal? Oh yes... nothing at all...

[basslinemaster]

I think this would increase sales by a lot. Say, for example, a company selling a £99 synth gave the option of paying three monthly instalments of £33. They could initially offer you a version that had a one month expiration in the copy protection, so you pay £33, get a copy that will expire in a month's time, pay the second £33, and get a second copy of the VST that expires in another month, and then pay the final £33, and get a copy that never expires. Plenty of developers offer beta versions of programs they are working on, which expire after a set time, so that you have to download the latest version from them, so it isn't difficult to do.
If you couldn't afford to pay after the first month expired you would still have your payment counted in their system, and then maybe in a few month's time you could pay the next £33, and download the second copy which would expire after another month, and then pay the final £33 when you can afford it.

There's nothing in this proposal which would be attractive for a developer unless you can prove your theory that it would increase sales at all (let alone 'a lot') is other than entirely speculative.

What level of experience do you have in the relevant aspects of business (sales, finance, marketing, customer relations etc) which has led you to the conclusion that what is effectively a punctuated finance scheme with additional DRM/finance/administration overheads would ultimately be significantly successful for any software businesses, let alone this fairly small niche?

You've taken your time... I thought you would have jumped on this the second after I made my first post, after all, you sure don't like people coming up with original ideas on KVR... LOL.

"a punctuated finance scheme". What are the "additional" "finance/administration" overheads?

The move of Adobe and other huge software companies to SaaS tells me that they believe they will make more money by letting their customers pay a small fee regularly, rather than a large fee, once.

Is that good enough evidence for you? And who would it hurt if they tried it? Did you even read my post about how you would set it up in an e-commerce site?
You add a new product, "One month trial of product X" for £33. That takes about two minutes. The customer gets 10 points/vouchers when they buy it. They can wait as long as they want before buying it again. They then get another 10 points/vouchers. You do realise that e-commerce systems do all the work for you, right? You don't have to manually send the customer the file, etc... Then they can use the twenty points/vouchers they have, for a £66 discount on the full priced, unexpiring version of the software.
We are talking about a one off two minutes of work to add the new product to the site, and however long it takes to implement the one month expiry DRM, (or it could be 100 hours, or 100 uses of the software, etc.) That is IT. Nothing else.

[basslinemaster]

http://help.x-cart.com/index.php?title= ... ial_Offers

[beely]

See my previous post - you add ONE new item, it takes about three minutes, I do know how to set up e-commerce sites...

It's easy to trivialise things. The are more complicated factors here. What if the ecommeice site the dev uses doesn't support this? Switch to a whole new ecommerce webstei system? Or what if they use their own hand-rolled system and would have to build it in?

In some circumstances it might be relatively easy but not all of them.

No, no need to change the customer database, I've just explained how it works with tokens/vouchers/points.

Ok, support request coming in - let's lookup this customer. Ok, he paid for one month of use of the product last year. So he's not a license holder. And no he's trying to sell his part license on to someone else on KVR... sheesh!

You are being a bit naive in your trivialiing everything, because that's only a best case and the best case happens in only a small percentage of the time. Existing developers are telling you why your simplistic view isn't practical, but you can't listen. This shows some naivete in how these things work.

Are you serious? You're clutching at straws here.

No, I just just giving you some examples of the additional burdens that support would be placed under.

And so what? You deal with them.

How much extra support burder?
How much extra sales?

Back to the formula...

Anyway, waste of breath, you aren't really listening to what experienced people are telling you, and are assuming the best simplistic cases and assuming that literally all you have to do is spend ten minutes editing an online form and Boom! - Double your sales!

It just doesn't work like that in practice, no matter how much you like to believe it does.

Like I say, it might work for some people and some products, but it's not commonly done, and you have to realise there are *reasons* for this - it's not like developers just don't want to bother much about getting sales...

[kbaccki]

And this is what's even more incredible - that the likes of kbaccki think they are scoring points over a mere idea, by revealing that they don't even understand how an e-commerce site works.

kbaccki is a professional software developer since 1993. I was developing online movie ticketing, catalogs, direct hardware sales, etc. when Java was still at 0.9beta and shopping carts were implemented in Scheme using some newfangled "cookie" browser technology.

I don't know what your background is, but statements like "just pay a developer to do it in ten minutes" leads me to believe you're prone to hand waving. Sorry.

[beely]

The move of Adobe and other huge software companies to SaaS tells me that they believe they will make more money by letting their customers pay a small fee regularly, rather than a large fee, once.

Is that good enough evidence for you?

When I raised this point (as an aside about different payment models) you stated it was irrelevant to the conversation. Now you are using it as "evidence" to support your idea.

Your statement is true, but these are different factors (more about how to make mature software generate revenue in terms of declining update sales).

Or at least, the last time I looked I couldn't buy Photoshop in installments, merely rent it for continued use. If you can purchase a standalone license in installments, then I apologise.