Why do people want everything for free when other have put a lot of effort on making it?
I don't think that's the problem. People will pay if what you build solves their problem. More specifically, they'll pay if they see that what you build solves their problem.
Before building, you should check:
1. Do they have a problem?
2. Do they know they have a problem?
3. How much of a problem is it for them?
4. Who, exactly, has the ability to act on this problem?
5. What language do they use to describe the problem?
6. Do they have any requirements that aren't obvious to me? Can I incorporate them into what I'm building?
If this sounds like marketing, it is, but it's the good sort. Building something people don't actually want is a perennial problem.
Rather than trying to sell what you have, figure out what they want. Then you'll know whether to:
I actually just had this experience. I was in need of a simple REST client to test APIs, and I know I could write one, but I figured I'd do a quick and dirty search and went to the Mac App Store to see if there was a decent free one. None of the ones in there were free (which I expected, because putting stuff in there isn't free). I found the highest rated one, went to the developer's site and downloaded the trial. The software is great, and it has more features than I could possibly have imagined, many of which I won't even use. It also has some idiosyncrasies that don't fit in with my workflow. So now I'm stuck with the question of whether or not I want to buy it anyway, or build my own, which I know I could.
OP is fighting that urge, especially since they're not selling a full packaged solution outside of badge creation - namely, identity management, or security access controls, etc. Customers may not be thrilled with the manual process, but don't find it a problem they'd spend money on. You have to know your audience, and either appeal to their problem, be cheap enough that it doesn't matter, or abort.
Comments
I don't think that's the problem. People will pay if what you build solves their problem. More specifically, they'll pay if they see that what you build solves their problem.
Before building, you should check:
1. Do they have a problem?
2. Do they know they have a problem?
3. How much of a problem is it for them?
4. Who, exactly, has the ability to act on this problem?
5. What language do they use to describe the problem?
6. Do they have any requirements that aren't obvious to me? Can I incorporate them into what I'm building?
If this sounds like marketing, it is, but it's the good sort. Building something people don't actually want is a perennial problem.
Rather than trying to sell what you have, figure out what they want. Then you'll know whether to:
1. Change who you're talking to
2. Change how you're talking about the product
3. Modify the product
4. Abandon ship
I actually just had this experience. I was in need of a simple REST client to test APIs, and I know I could write one, but I figured I'd do a quick and dirty search and went to the Mac App Store to see if there was a decent free one. None of the ones in there were free (which I expected, because putting stuff in there isn't free). I found the highest rated one, went to the developer's site and downloaded the trial. The software is great, and it has more features than I could possibly have imagined, many of which I won't even use. It also has some idiosyncrasies that don't fit in with my workflow. So now I'm stuck with the question of whether or not I want to buy it anyway, or build my own, which I know I could.
OP is fighting that urge, especially since they're not selling a full packaged solution outside of badge creation - namely, identity management, or security access controls, etc. Customers may not be thrilled with the manual process, but don't find it a problem they'd spend money on. You have to know your audience, and either appeal to their problem, be cheap enough that it doesn't matter, or abort.