Comparative Pricing - where you look for something similar and charge much the same.
Cost-based Pricing - where you figure out how much it'll cost you to produce, and then charge accordingly (with a profit margin, we hope).
Value-based Pricing - where you figure out how much the thing is worth to the customer, and charge that.
You should do "value-based pricing", as a general rule. But never go below your cost, and don't go too far off the price of your competitors of course.
This is not helpful advice, of course - it's really saying "do all three".
But let's assume you're a student, and your general living expenses are covered, so cost-based isn't much of a worry. That leaves comparative pricing and value-based to consider.
There's two ways that someone might pay for a bit of automation software. They might want to pay for it all up-front, once delivered. Or, they may prefer to pay for it as a service, on a monthly fee. A lot of software - and I mean, a heck of a lot - is a mixture. People pay for an initial "license fee" or similar, and then pay for a "support contract". These correspond to "CapEx" (Capital Expenditure) and "OpEx" (Operational Expenditure). Different businesses have different priorities here, but most will want to push toward high CapEx and lower OpEx - because lower OpEx leads to higher long-term sustainable profit.
Okay, business finance lesson over.
If you want to go a value-based route, try to estimate how much money this software will save (or earn for) the customer, and aim to take a cut of that (10% or so). You can then decide how much to take as "support" and how much as "development" - in general, the further in the future your OpEx saving would be, the less it would be when converted to CapEx. This way, you'll be able to say "This project will pay for itself within X weeks" - where X is usually going to be a pretty low number. By doing this, you'll literally never overcharge your customer.
But in this case, I suspect you want to run it like a consultancy - so you're going to charge a "day rate" during development, and hand over the result unsupported at the end.
This leaves two questions:
How many days?
How much per day?
The first is best answered with an estimate (from you), and an agreement that the software is delivered on an agile basis, with your customer involved in the sprint process, week by week, on a pure T&M basis. In other words, there's no hard minimum or maximum, but the customer has a good guide price and clear involvement across the entire development process. They can stop at any time they want.
The second question is where we go "HOW MUCH!?!?!!", because typical day rates run from €250 to €1000, depending on the rarity of the skillset. You can, of course, go lower if you want (or, indeed, higher).
So do the CapEx/OpEx guesswork above, then estimate how long it'll take you, divide one by the other to get your day rate, and then decide if that amount of money works for you.
Confused? Yeah, so am I, which is why I keep out of pricing discussions and don't do consultancy work anymore.
There are three ways of pricing anything:
You should do "value-based pricing", as a general rule. But never go below your cost, and don't go too far off the price of your competitors of course.
This is not helpful advice, of course - it's really saying "do all three".
But let's assume you're a student, and your general living expenses are covered, so cost-based isn't much of a worry. That leaves comparative pricing and value-based to consider.
There's two ways that someone might pay for a bit of automation software. They might want to pay for it all up-front, once delivered. Or, they may prefer to pay for it as a service, on a monthly fee. A lot of software - and I mean, a heck of a lot - is a mixture. People pay for an initial "license fee" or similar, and then pay for a "support contract". These correspond to "CapEx" (Capital Expenditure) and "OpEx" (Operational Expenditure). Different businesses have different priorities here, but most will want to push toward high CapEx and lower OpEx - because lower OpEx leads to higher long-term sustainable profit.
Okay, business finance lesson over.
If you want to go a value-based route, try to estimate how much money this software will save (or earn for) the customer, and aim to take a cut of that (10% or so). You can then decide how much to take as "support" and how much as "development" - in general, the further in the future your OpEx saving would be, the less it would be when converted to CapEx. This way, you'll be able to say "This project will pay for itself within X weeks" - where X is usually going to be a pretty low number. By doing this, you'll literally never overcharge your customer.
But in this case, I suspect you want to run it like a consultancy - so you're going to charge a "day rate" during development, and hand over the result unsupported at the end.
This leaves two questions:
The first is best answered with an estimate (from you), and an agreement that the software is delivered on an agile basis, with your customer involved in the sprint process, week by week, on a pure T&M basis. In other words, there's no hard minimum or maximum, but the customer has a good guide price and clear involvement across the entire development process. They can stop at any time they want.
The second question is where we go "HOW MUCH!?!?!!", because typical day rates run from €250 to €1000, depending on the rarity of the skillset. You can, of course, go lower if you want (or, indeed, higher).
So do the CapEx/OpEx guesswork above, then estimate how long it'll take you, divide one by the other to get your day rate, and then decide if that amount of money works for you.
Confused? Yeah, so am I, which is why I keep out of pricing discussions and don't do consultancy work anymore.
I think I got your points! Thank yoy for the comment!