1. You hone your skills through years of on-the-job experience with real-world problems.
2. You have some spare time and / or some savings that allow you to take less work for a while.
3. You want to strike out on your own and build your own software product.
4. You’re waiting for *the* idea. Which doesn’t come.
5. Back to 1.

Trying to come up with the perfect product idea can be paralyzing. In this post I’ll propose a framework for coming up with product ideas based on research and your personal experience. So lets get started:

Customer needs + market experience = WIN

If you have years of experience in a specific market – such as game development, eCommerce, travel software or content management – use that experience to your advantage when considering product ideas.
Even if you are a bit tired of working in that field – your knowledge of the market, existing products and customer pains will typically result in a much better product than you can hope to create in markets you have no first-hand experience with.

A few questions you should answer based on your market experience and with a bit of research:

• Who are the big players in my field? What are the successful products?
• Which are the products that I personally adore and why? Which products are successful despite being superficially bad?
• What would I do differently if I were building any of those products?
• What pain or need is not being answered adequately by existing products? what feature or issue did I see most often while working in this field?
• Is there a way to port some of those products to a different field? How about importing products from other fields into this one?
• Would combining existing products make for a better product? What about simplifying and removing features instead?

As a software developer, I assume you have your own research methodology. To be thorough, I’ll present my own channels for such research:

• Google is your friend. Well, not really – but it does provide pretty good search results. Use it!
• Visit community sites – forums, Q&A sites and the like – for the audiences in your field. It could be service providers (including developers) or the customers themselves. What problems come up often? what are people talking about? engage other people in active discussions to learn more about the source of those pains.
• If you have any, talk with your customers about their day-to-day activities. Are they doing something inefficiently that could be automated? are they missing a tool that could be making their life that much easier or save them a ton of money?

Solve a big pain

It might be tempting to go after low hanging fruits and just add a feature or two to existing products. While iterating on existing products can work, competing on features could be difficult. Ask yourself – am I answering a big pain? or am I just scratching an itch?

In a similar fashion, don’t be afraid to build premium products in smaller or niche markets. Don’t try to maximize your audience by appealing to everyone and instead try to build a really good solution for a smaller audience. Premium products with higher price points usually mean better customers, less support tickets and better overall value for building a lasting business around.

We previously wrote about “Raising your prices to sell more” which makes a similar point – bigger, more specific solutions that are priced higher convey more perceived value and make for an easier sale – despite (or even thanks to) the higher price point.

Specific Examples – Open-source products

Lets narrow down our focus and talk about what we deal here on Binpress – open-source projects (if you have not considered open-source as a business opportunity – you really should).

Open-source code satisfies business needs for software projects. That includes anything from individual developers to startups to enterprise companies. We always found it easier to relate to the problems of other developers – being developers ourselves. We share many of the pains and need of our target audience.

Example 1: Building a Paypal API wrapper

If you ever worked with the Paypal API, you know what a sucky proposition that is (though they have been making some efforts recently to clean it up). Many of our early client projects required Paypal integration, and through much sweat and tears, we came up with a reusable solution that allowed us to integrate (relatively) effortlessly with Paypal on every new project.

Customer pain – Adding payment processing with Paypal
Market experience – Integration with the Paypal API in PHP

The result was one of our first products on Binpress – the PHP Paypal API class. Over the last 2 years, this API wrapper has saved countless hours for almost a thousand customers.

Example 2: Adding PDF capabilities to iOS apps

Though iOS has native PDF handling capabilities, it’s hard to get rendering right in a way that is both visually appealing and performant for the end user. One of our publishers, Kemal Taskin, distilled his years of experience handling PDFs in iOS apps into an SDK that allows every iOS developer to leverage that experience to deliver top-notch PDF support in their apps immediately.

Customer pain – adding robust PDF support in iOS apps
Market experience – years of optimizing PDF rendering on iOS

The result was one of the most popular products on Binpress – the PDFTouch SDK for iOS. This product has evolved over its lifetime based on customer feedback, becoming one of the industry standards for PDF rendering on iOS, and providing its publisher with silicon-valley comparable salary from developing an open-source project.

Example 3: Building an iOS platformer game from scratch

There are many tutorials and online code examples for getting started with game development on iOS. However, getting an appstore-ready game up and running is still a long and difficult journey. Florian Strauß, one of our German publishers, used his game development experience to create an appstore-ready starterkit for building platformer games, based on games he had previously published on the appstore.

Customer pain – developing an fully-featured iOS platformer game from scratch
Market experience – years of publishing games on the appstore

The result was a fully featured iOS Platformer Starterkit, that was featured on multiple tech news sites, including the frontpage of HackerNews.

In conclusion – TL;DR

Summarizing the points made in this post:

• Build a product in your field of expertise.
• Leverage your market experience and market research to understand what problems are worth providing solutions for.
• Create better products by solving bigger problems and building premium solutions.
• Some concrete examples of successful commercial open-source products.
• On Binpress we also have our component proposal section – specifically for the purpose of nurturing new project ideas.

I hope this post has given you some food for thought. We will be expanding this topic in the future, as well as discussing the other aspects of creating a successful products – such as marketing, sales, pricing and more.

Have any questions? leave it in the comments!

In the context of free and open-source software, free refers to the freedom to copy and re-use the software, rather than to the price of the software. … one should “think of free as in free speech, not as in free beer”.

Wikipedia on Free and open-source

The accepted definition of the ‘free’ part of ‘free open-source’ does not talk about being free as in costs no money (free beer) but about the freedoms afforded to the user of the software – being able to read, modify and distribute the source of the software (as in free speech).

This is an important distinction – as free-in-cost got attached to the term open-source, but does not actually define what open-source is. Put in other words, the philosophy of open-source values freedom of use but says nothing about the cost of distribution by the copyright holder. This is the main concept behind Binpress – that the availability of code and the freedom to use it is the main benefit of open-source, and we should support that by building a business environment that encourages and supports the sharing of code in a sustainable way.

Are all of our licenses compatible 100% with this definition of free? no. There’s a price-freedom optimization that allows to provide different pricing for tiers of freedom depending on yours needs. If you don’t need the freedom to redistribute, but just modify and use the code in your application, you can obtain the same results at a reduced price. That’s basic market economics.

Resistance to change [cost > 0]

People don’t want to pay for stuff they are used to get for free. That’s just common sense. Most of the available open-source code is free as in free beer in addition to being free as in free speech. Naturally, when you start a movement whose goal is to change that, you’re going to encounter resistance.

That resistance breaks when you have a problem that doesn’t have a free component. Then, the value talk is different – paying for a solution that saves you > x10 times in costs / time suddenly makes sense. And the fact that paid licenses were able to sponsor the existence of that solution now seems like a good idea.

We previously covered how the donations model does not help sustain open-source projects. Giving a developer a pat on the back is different than supporting his efforts in a substantial way. While Apple is trying it bottom out developer compensation with its pricing strategy, we are trying to do the opposite by creating a revenue channel for developers willing to create new value to the software community.

An old concept, now streamlined

Commercial open-source has been around for a while. If you have any connection to the software industry, you’ve heard about MySQL, Redhat, Magento and similar companies making big businesses from open-source products.

With Binpress our intention is to give developers tools to replicate the process those companies went through, while abstracting the parts generally not a part of a software developer’s toolset – marketing, distribution, sales, licensing, pricing, payments and fees. With a centralized market for curated open-source products, published projects also benefit from sharing the audience with many other projects – the “Appstore” effect. Curation is an important part, preventing quality being drowned in a see of noise.

So next time you shout out “but open-source is supposed to be FREE!”, keep in mind what kind of freedom we are talking about. And it’s the important kind.

I don’t have authoritative numbers, but from asking around and being involved in the community (mostly as a consumer of open-source), it seems that donations are rarely a driving force behind open-source. Why aren’t donations effective for open-source?

Can’t live on donations

How can donation money be used by open-source projects? Jeff Atwood was surprised to find out his $5k donation was left unused months after he had sent it to a .NET open-source project. He asked his friend, Jon Galloway, which responded “Open source projects run on time, not money. [redacted]“.

To progress, an open-source project needs the same resource as every software development project – developer time. You need dev time to fix bugs, you need dev time to add features, you need dev time to write documentation. If the donation stream is not regular and dependable enough to allow project team members to either quit their jobs (if working full-time) or reduce contracted hours (if working freelance), then donations are not going to add more dev time to the project. If you can’t depend on funds from donations, they are relegated into the “nice-to-have” category. You can use it to pay off some external costs like hosting or running some ads (if it makes sense), but you can’t use it for anything important like salaries.

Donations for open-source lack the urgency and personal empathy that charity causes have – such as donations to find a cure for a terminal disease or solve some ecological issue. The audience for those causes is much larger, and they make a much stronger emotional plea than open-source – and in any case, most open-source projects don’t “need” the money like those charities do – and so it’s usually phrased in a way like “buy the developer a cup of coffee”.

The main purpose of donations to open-source is to say “Thank you” to the developer(s) rather than actually advancing the project. “Submit a patch” is a common response when you open a ticket that is not interesting / urgent for the project maintainer. It’s never “send a donation”. Because donations can’t buy dev time.

For smaller open-source projects, this is usually not a problem. A small audience, limited use-cases and a small code-base mean less dev time is needed to support it. Once a project crosses a certain threshold of either popularity or complexity, developers who are paying the bills with other work have to start prioritizing on what to work on and what bugs to fix.

At this point one of 3 things can happen -

1. The project will grow popular enough that it can be monetized (through premium licenses, support, or being bought off by a large company) that the original maintainer can dedicate himself to it (and maybe even grow the team).
2. The project will grow popular enough and open enough (i.e, the original maintainer cedes control to the community) that the community can maintain it. Most projects do not cede this control though, and the bottleneck remains developer time of the original maintainers.
3. As the project consumes more and more time just to maintain, developers get frustrated with the increasing number of (terrible / irrelevant / hard-to-fix / hard-to-reproduce) bug reports and not enough time to work on the parts they really want to. This is where many open-source slowly die off.

Those options are ranked from the least likely (commercially viable) to the most likely (dying off) outcome.

Promoting open-source projects up the ladder

This is the main problem we are trying to solve at Binpress (the blog of which you are currently reading). How can we get more developers to -

• Release more code into the open, reducing redundant development
• Support and advance their open-source projects full time
• Treat their open-source projects like they would their paid-for projects – i.e, like a professional business

The last part is of special note – we feel that treating open-source projects like a professional business, instead of a hobby or an altruistic endeavor is the key for sustainability for most projects. While the last 2 are admirable and open-source would’ve never have become as big as it is without them, they remove an important level of responsibility developers feel when providing support for their projects. As the initial enthusiasm wears off, complexity increases and issue reports start piling off, it’s hard for developers not to become less than cordial when providing support, or even not to provide support at all.

How do we do it? Binpress is a platform (marketplace) for developers to:

1. Publish their open-source projects. Submissions are curated – we check that the code works, that it is well documented and follows a consistent coding style, and lastly that the project is not trivial. As I mentioned earlier, the need for a project to work like a business arises only when complexity / importance reaches a certain level.
2. Gain visibility for their projects – we handle marketing, advertising, SEO, send out newsletters, reach out to communities, collaborate with relevant players in the field – all to bring attention to projects that passed our curation. Basically all the stuff that most developers hate to do and / or suck at.
3. Find a licensing / pricing structure that works for them. We have created a license generator in cooperation with copyright lawyer (and open-source advocate), Jon Klinger. More on licensing below.
4. Handle payments and payouts – we collect payments (for non-free licenses) through a variety of payment methods and issue payouts either through Paypal or a direct bank deposit. We swallow the various fees in our commission, making the process much smoother for developers.
5. Provide communication channels and social proof, such as comments, reviews, feature suggestions, and of-course – issue tracking.

While a few of those attributes may remind you of open-source directories such as GitHub and Google Code – Binpress is an extension of those and not an alternative. In fact, we have an integration with GitHub that allows developers to add the commercial business layer on Binpress while hosting their code on GitHub.

About ‘free’ and ‘open-source’ – while the two have historically been conflated together and it’s hard to pay for something you are used to get for free – we believe that for open-source to mature from a hobby to a professional business, some commercial elements need to be introduced, whether it’s through the sponsorship of a big company like Google, paid support or paid licenses. The important thing is to enable the sharing and support of quality and useful source-code, and treat it like a professional business.

Many open-source projects have taken this route independently, and the few that have been highly successfully set an example for the rest. Projects such as MySQL, Magento, Redhat and SugarCRM has shown how well this model can work, and we are trying to make it as accessible and available to any open-source project who wants to graduate from a hobby / pastime project. Not everyone agrees with this model – it’s hard to pay for something you are used to get for free – but we believe the outcome is a better, more sustainable ecosystem for sharing code.

Only the beginning

There are many developers making a good living from publishing their code on Binpress. Some are making silicon-valley comparable monthly salaries – for getting to work and support their personal projects. We think that’s pretty cool – but we’re just getting started. We haven’t exhausted all the possible ways for developers to support their projects full-time other than paid licenses.

For example, right now support is baked into the license – but we intend to make it independent to allow free open-source projects to monetize their support. We are still thinking about the specific implementation such as paid tickets vs. support periods, and whether to allow a mix of free and paid support (for example, bug fixes for free and new features are paid). We’d love to hear some feedback from the community on how they would like to have paid support added to their open-source projects.

Another option is customization services for open-source projects. We get many requests from clients who buy or download free components on our marketplace to provide post-purchase services for customization and further development based on the project. Right now we connect them to the developers manually, but we would love to offer the option for developers to provide such services for any open-source project they developed or are experts in.

Keep moving it forward

Getting more developers to share quality code and then support it as a professional business, while providing a curated inventory of code solutions to speed up development and increase robustness of projects, is a win-win proposition for both publishers and consumers of code.

We have been picking off steam as of late, and are seeing real validation that this concept can work and scale. We have been accepted into the 500 startup #6 batch which starts mid-April – we’re very excited about that and hope they can help us leverage our current momentum and help us take the open-source industry to the next level.

We are hiring! if you find our views compatible with yours and think you can contribute – especially in marketing, sales or community management, please send a quick shout-out to our CEO, Adam (email – his name[at]our domain).

You should also read our follow-up post on the subject titled Freedom, beer and open-source.

1. End the price with a 9. It beats every other number, even lower numbers as pricing (for example $39 beats $37).
2. Shorter prices look less expensive. Drop the decimal point and even commas from the number.  Similarly, 99$ looks less expensive than 100$. We will soon be testing it here by removing the .99s from all of our prices.
3. Anchor your pricing. This is a common advice we give to publishers – always put at least 2 licenses with different pricing. Quoting Hiten:
   The easiest way to make your price look good is to anchor against some other price. This is why many retailers will list the MSRP right next to their actual price. It looks like a hefty discount even though it isn’t.
4. Offer multiple choices. Similar to the point above, and I’ll repeat our advice – put up multiple licenses! Quoting again: Customers at lower price-points tend to demand a lot more time from support and don’t have great margins to begin with. Depending on how your customer base grows, you may want to drop your lowest price completely.
5. Double Your Prices. We just wrote an entire post on this subject, and apparently we’re not the only one seeing this effect. Higher prices -> much higher revenue -> better margins -> better ratio of support / income.
6. Test your pricing. We covered this in our original science of software pricing piece. Don’t be afraid to experiment with your pricing – but give it enough time to get useful data (about a month or two should be enough).

On a different note, we have been on a tear lately. Binpress has closed consecutive record months in revenue, and this one is already shaping up to beat them all. If you have good code, now is the time to publish!

This time we want to share some insights from over 2 years of running Binpress, about what components sell the most and generate the most revenue, and how it relates to their pricing (and licensing). While we’re talking about Binpress components here, this article is relevant for selling any kind of business or developer oriented software.

Higher priced components sell better and generate more revenue. And it’s not even close

Lets compare some sales numbers between lower and higher priced components.

• Components priced at 100$ or more generate 51% more sales compared to lower priced components.
• Components priced at 100$ or more generate 1,269% more revenue compared to lower priced components. Yep, that’s a factor of more than 12 higher revenue.

If those numbers surprise you, it might be because it goes a bit against common logic. Sure, higher priced products generate more revenue per sale, but that should be offset by people buying more of the lower priced products. Right?

Well, it turns out that conventional wisdom is not really applicable here. Lets explore reasons to why that is:

• Buying components is not an impulsive purchase. People pay for components to solve a need, and after doing due diligence and research first.
• That need is usually a business need and not a personal one. People are willing to spend more when they believe they’ll have good ROI (return-on-investment).
• Higher priced components usually solve bigger / more painful problems. The smaller a problem is the easier it is to ignore it, and vice-versa.
• Higher priced components represent higher quality and set expectations accordingly. When purchasing the question is less about price and more on whether it’s within your budget. If it is, the exact number doesn’t matter that much – and better solutions are preferred.

Touching more on the first point, many publishers come to Binpress with experience in software marketplaces such as the App Store or Google Play, and are used to selling low-priced software and hoping to reach a mass-audience. Binpress’ audience is completely different – in size, in disposition, and in their motivation for purchase. For those reasons, applying App-Store like pricing schemes on Binpress is counterproductive.

Raising your prices does not affect conversion

Here’s another punch in the face of conventional wisdom – generally speaking, raising (or lowering) component prices on Binpress does not have much effect on purchase conversion.

This is true up to a point – there seems to be a (pricing) cliff for most people below which a sale would occur. That cliff is individual and changes between person to person, but in general it is much higher than you think. Once you satisfy the “need” portion of the equation with your component, the main question is whether you fit in the budget.

There is an exception to this rule, and that is providing discounts. Giving a discount gives the feel of greater value and urgency – especially if it time limited.

Two prices are better than one

Many components are submitted for review with one license and pricing attached, and we always recommend having at least 2, each with its own pricing. The goal is to have tiered pricing, where the lower tier(s) appeal to individuals and smaller companies and the higher tier(s) appeal to bigger / higher budget companies.

The motivation is that pricing does not exist in a vacuum – creating a point of comparison between different pricing changes the perceived value of each – with the lower tiers appear to have better value and the higher tiers appear as more premium.

In addition, giving clients the option to spend more (while providing more – with different licensing), can only have a positive effect on the bottom line.

You need to sell less to make more with higher pricing

While a fairly obvious point, it is one that is commonly overlooked by publishers we talk to. Even if you are afraid that higher prices will reduce sales, keep in mind that you need to make less sales with higher pricing to generate the same revenue.

Do you think that raising your prices by 50% will hurt your sales by 50% or more? most likely, that is not the case. From our research, raising prices by 50% will hurt your sales on average by 5-10% (and sometimes not at all). Again, it is all a matter of staying within the budget of your target audience, and representing the value of the component well.

There is also actually a side benefit to making less sales, in case that does occur – you have to provide less support. Your time is valuable, and you should consider time investment in support when pricing your components.

To the bigger component goes the spoils

After reading all of this and going over your components, you still can’t justify going over a certain pricing point. The solution – publish bigger components! publish components that justify a higher pricing point, and price them accordingly.

That’s the most important advice we can give to current and potential publishers – if you can’t decide in what component invest time in getting ready for publication, always go with the bigger solutions that solves a bigger need. The rewards for publishing a bigger, higher priced components are simply not proportional to the time investment, as shown in the numbers in the beginning.

Some inspiration

Want to see some of our best components and get some component idea inspiration? take a look at the following:

• RadioTunes SDK for iOS. One of our all-time best sellers, and has spawned a family of components for various platforms, such as appcelerator and Android.
• PDFTouch SDK for iOS. From the same publisher as RadioTunes above. This guy really gets it with regarding to pricing and presentation.
• Commander Cool iOS platformer Starter Kit. Game starter kits have been all the rage recently on Binpress.
• PepperUI for iOS is a relatively smaller component compared to those above, but with the right value proposition and pricing, generates nice revenue.
• The recently launched iPad Book / Newsstand component has been doing very well. The publisher used our component incubator to great effect, building an audience before even writing a single line of code.

If you have any questions regarding pricing or component ideas, leave a comment or get in touch through our contact form. We are here to help

We are not Github

Github is “social coding” – a Git repository service with social elements baked in. People publish their code and other people can follow their progress, submit issues or even contribute code (depending on permissions).

On the other hand, Binpress is a curated inventory of solutions for common needs in software development. It is a not a collaborative coding environment, but rather a publication platform for code authors. Elaborating on those differences:

• “Projects” on Binpress are called components to distinguish them from “snippets” and must meet a minimum threshold of non-trivial code while demonstrating usefulness.
• Components must adhere to our publication guidelines. This is what we mean by curation – We manually inspect each component for coding standards and implementation details. Github has 3.5 Million repos – not easy to find quality projects that don’t have significant traction (by the way – they just went over 2M users – major props to the Github team!).
• We provide a licensing system that allows for both free open-source and commercial open-source licenses. More on why below.
• We provide a marketing layer to get attention for published components. We help component publishers write marketable description and content, we drive traffic to their component pages and we design those pages to look professional and attractive.

Github projects can be published on Binpress, either by connecting through a Github account and automatically importing it or by adding it manually. The reasons why someone would publish on Github and on Binpress are different – We are symbiotic to Github, not competitors – they drive traffic to us when our publishers use public Github repos, and some of our publishers create private repos on Github to host commercially licensed code. (they also sponsored us on several past events)

Commercial Licensing Is The Devil?

Another question that sometimes pops up, usually after the Github question, is why do we allow / provide the option for commercial licensing on Binpress?

Some developers, who normally have no qualms about monetizing every other aspect of their work, become very defensive when you take the ‘free’ out of ‘free open-source’.  There’s a sense of entitlement in software development, that is the result of having being poiled by some great free open-source projects over the years. Publishing a free open-source project is not for everyone – isn’t it better to have more (quality) code available regardless of pricing?

I understand the value of my time. I not only have an hourly rate, but I also grasp the value of getting ahead of a schedule, or being able to meet an aggressive schedule without having to compromise functionality or vision. The idea of paying others for quality source code is something I find very easy to accept and understand. -Matt Gemmell, Selling source-code

I already wrote in detail about how commercial and free licensing supplement each other as a necessary balance in the industry (you should really read it if you’re interested in the subject). TL;DR:

• There’s no contradiction – as there isn’t between commercial businesses and not-for-profits. We applaud people who can afford to dedicate the time and effort to support a free open-source project, but also welcome people who want to make it a professional business.
• The software market is huge and rapidly growing – and it cannot be sustained by free software alone (this is where the nitpickers say – we only want the code for free, but the correlation is the same).
• Most big name open-source products have a commercial element that makes them a viable business (Mozilla, MySQL, Magento, Redhat, to name a few), and sustains their development and support.

We believe treating code release as a business can have positive benefits -

• It raises expectations and accountability
• Supports further development
• Frees up the developer to allocate time and attention
• Handled like a professional project
• Another option for software engineers to make a living

While some highly prolific open-source projects got to that level without commercial licenses, they are the exception, not the rule. Many open-source projects that have since gone defunct could have been supported by adding a commercial license or other form of monetization.

If it’s really about keeping people from reinventing the wheel, then give the wheel designs to everyone for free. -Jeremy Russel in an HN comment

A common comparison, but a particularly bad one – Components on Binpress are not the concept of the wheel, they are implementations of wheels. Demanding that they be released for free is analogous to asking wheel companies to give away free wheels since they are important for making cars. It’s up to the wheel companies to make that decision, and luckily Binpress publishers are much more accommodating since we have about a 50-50 split of commercial and free licenses (including dual-licensing).

Personally, I feel that if a concept or a method is fundamental or ubiquitous enough then it should be available for free – in that case the wheel analogy makes sense. And yet, just consider for a minute how many of those are patented by your favorite technology company.

The Ecosystem of Software Development

You are wasting an outlandish amount of money writing code that already exists. -Joel Spolsky, Things you should never do

The goals everybody in the industry should have are shorter development lifecycles, lower development costs and more focus on the unique value their product creates. Using off-the-shelf solutions to solve the non-core needs is a very effective way to achieve that.

Is Binpress the solution? that remains to be seen. Sure enough, our inventory is still small compared to the amount of common needs in our industry, but it’s growing daily and hopefully one day it can be that solution. You are welcome to add your project if you feel it meets the requirements and can be useful to other developers.

If you made it this far and you develop software, I’m sure you have an opinion about the points made in the article. Let us know what you think in the comments below.

The top 3 contributors are:

1. Mark Petherbridge, with a score of 6217 (nice job, Mark!). Mark wins a PlayStation Vita console (sponsored by Nexmo), and 12k$ worth of cloud hosting and services from our sponsor, Rackspace.
2. Tope, with a score of 2892. Tope wins 1.5k$ worth of cloud hosting and services by rackspace.
3. Kemal Taskin with a score of 2382. Kemal wins 1.5k$ worth of cloud hosting and services by rackspace.

Congrats to the winners and all the other community members who participated. We’ll be looking to spice things up and add more special prizes, especially for the 2nd and 3rd places, soon.

Big thanks to our sponsors Rackspace and Nexmo for contributing the prizes and sponsoring the content. A special mention goes out to Florian Strauß, that while didn’t participate directly did an incredible job of promoting his new component, Commander Cool, and had excellent results to show for it.

Looking forward to seeing what you guys can come up with this month!

The situation is even more problematic for digital products, in which case credit-card companies or Paypal refuse to provide any kind of seller protection. The reasoning behind it is that digital product fraud does not result in actual material loss, and it’s hard to prove delivery – both are false, but the situation stands as it is anyway.

As a marketplace for digital products, Binpress has been hit by its share of online fraud. We used to accept both Paypal and credit-card payments (through stripe), and both have been abused in various ways.

You can jump directly to the fraud prevention measures if you are already familiar with the fraud methods.

Fraud methods

Paypal

Paypal promotes itself as a more secure payment method by removing the need to enter credit-card details online. In reality, Paypal account credentials can be compromised just as easily as credit-card details, and it still has the vulnerability of credit-card payments (unless you disable that feature).

Paypal can be abused in several ways, so lets go over the main attack methods:

Paypal account hijacking

By getting a hold of Paypal account credentials or an active logged-in session, an unauthorized user can make payments using Paypal as if he were the real account holder.

This route is very advantageous to the attacker – he does not have to pass all the checks banks employ on credit-card transactions (address, zipcode, CVC) and use the account to pay immediately.

Paypal payments with stolen credit-card details

Paypal allows people without an account to pay directly with a credit-card (unless you specifically disable that option). This means that stolen credit-card details can be used – the same as with every credit-card payment option (which will be covered in more detail in the next section).

Fortunately (or not), Paypal has its own fraud detection mechanism that it uses on credit-card payments. This means that credit-card payments on Paypal are less likely to be stolen, but on the other hand Paypal often rejects legit payments that fail their somewhat strict detection system.

Paypal disputes on legit transactions

In a way, this is the most troublesome fraud of all. The transaction itself will appear completely legit, as the account owner in fact authorized it. What we deal here is “buyer remorse”, where the buyer simply decides he does not want to pay for the transaction, and opens a dispute on Paypal.

Paypal will side with the buyer most of the time, unless you can provide strong evidence of delivery (for example, a sign-off on a shipping paper). To some degree, Paypal will offer payment protection on certain products. Unfortunately, digital goods are not included and Paypal provides no guarantee of protection for those kind of transactions.

Credit-card transactions

Unauthorized transactions

An attacker will attempt to make an online payment by getting a hold of credit-card information. The information can start at only the card number, and extend to expiry date, CVC and even address details.

Unfortunately, confirmation of credit-card details across banks is very inconsistent. Some banks do not even check the expiry date or the CVC security code (!), while others might return a false positive (it would’ve been better if they had returned “not checked”).

To make matters even worse, a bank might approve a transaction even if some of the details were checked and confirmed as incorrect. This attitude extends to some payment gateways, which will leave the decision up to the bank and will not deny a transaction if some of the security checks are false. (We use Stripe by the way, which follows this approach).

Chargebacks on legit transactions

Similar to the Paypal option, a person who paid with a credit-card can later disavow his purchase by filling a chargeback with the credit-card company. This process is worse than Paypal’s disputes, with the cost usually higher and a much lower chance of keeping the money from the transaction.

Fighting back

Recognizing fraud attempts

Before we can stop a fraud attempt, we must be able to recognize it before we process a transaction.

There are some indicators which should be used to detect frauds attempts, with multiple occurring at the same time indicating a higher chance of fraud:

• The billing country and the IP country (via geolocation) do not match. Advanced attackers will be using a proxy though, more on IPs and proxies later.
• Usage of a proxy to disguise location and attempt to avoid the previous indicator.
• IP country (via geolocation) is from a high-risk country.
• Usage of a free Email service for the provided Email (if you have an Email field in your payment form). Email accounts with private domain names are less likely to be used in a fraud attempt. Again, if the free Email service is from a high risk country, it increases our suspicion of fraud.
• An unusually large purchase. While by itself is not a real indicator, combined with any other indicator raises the chance of fraud, in addition to the risk of losing more value (in the case of physical goods).
• High velocity of purchases by the same person – multiple purchases in rapid succession over a short period of time are a good indication of a fraud in progress. The various ways to track a person between transactions are discussed below.

I will now suggest an actual process for getting the information needed for those indicators. You can skip any of the steps, but the more indicators you have the better you can assess the risk of fraud.

1. Check IP

Using the client machine IP, we can attempt to determine the location of the person attempting the transaction via geolocation. In addition to the standard IP headers, proxies might send the actual IP through a long list of alternative headers. See this StackOverflow question for such a list and mock code (in PHP).

Detecting and using a proxy alternative IP header is important for a couple of reasons -

• First, we have the actual IP to use in the next step – geolocation.
• Second, using a proxy by itself is a strong indicator of fraud. While not all proxy users are fraudulent users, fraud attempts are much more likely to use a proxy than your average user.

2. Fetching the client address via Geolocation

A geolocation service will receive an IP and send back an approximate address that corresponds to it. You can use a geolocation service via an API or via an IP database on your server. A good free database can be obtained from Maxmind, as well as a more accurate one and an API for a small cost.

Once we have the client IP from the previous step, we use our preferred method to fetch his/hers location through our geolocation service.

3. Compare client address to billing address

The rule of thumb is simple – the farther away the client current location is from his billing address, the higher chance we’re dealing with a fraud transaction. The chance of fraud increases even more when the location is confirmed from a set of high-risk countries (mentioned above in the list of indicators).

The billing address should be collected on the payment form for credit-card transactions, or via GetExpressCheckoutDetails API operation for Paypal transactions, before confirming the transaction (if you use the “Buy Now” buttons instead of the API, you’re out of luck. Consider switching to the API – we have a great Paypal API component for PHP that makes using it very simple).

Of course, an address mismatch by itself is no confirmation of fraud. People travel all the time to different countries and use their credit-cards to make payments online. We should use this information with the other indicators to assess the risk of fraud.

4. Check Email address

Note: this step is only applicable if you collect an Email address in your payment form, or use the Paypal API which provides it in the billing details.

As mentioned before, free Email services are much more likely to be used in a transaction – and especially if the Email service is a fringe, lesser known service. There is quite a comprehensive list over at Yahoo, and you should add the domains of each to the check you run on the provided Email address.

If the Email address is from a free service, we should take it into account as another indicator with the others covered so far.

5. Consider size of transaction

Larger transactions are more likely to be fraud than smaller transactions. When we have hit several indicators already, the size of the transaction should be used to downgrade or upgrade the chance of possible fraud.

In addition, calculate the possible losses according to the size of the transaction (especially if dealing with physical goods), and use it to lower or raise the bar for which a transaction might be flagged as a possible fraud.

6. Review bank credit-card checks (credit-card transactions only)

This step does not apply to Paypal transactions as they run their own fraud detection system and do not provide such information before completing the transaction.

Most payment gateways will allow you to receive the results of the checks the bank runs on a credit card before completing a transaction.

For Stripe users - If you use Stripe, like us, you might not realize they do provide this option, though not directly. You can get the results of the bank credit-card checks by creating a customer with the payment token before actually processing the transaction, and then deleting the customer once the transaction has been processed. Ideally, they would have provided this information when the token is created, but currently they do not.

The fields banks can validate aside from the actual card number include the Zipcode, CVC security code (found on the back of the card), street address and expiry date. Different banks run different checks, and you might decide to reject a specific card on the grounds that his bank does not provide enough security information (such as not validating the CVC or expiry date).

I personally consider CVC, Zipcode and expiry date mismatches as showstoppers. Those are details that cannot be incorrect, while the address field is a bit harder to validate (everyone writes addresses a bit differently, and it’s also hard to correctly write down foreign street names in English).

Making a mistake on any of those does not necessarily indicate fraud, but should stop the transaction. Making multiple mistakes in rapid succession though is a good indication of a fraud attempt.

7. Check the logs

I will cover the actual logging of the transaction in the next step, but before we get there in the actual process, we want to check our logs for suspicious behavior. Suspicious behavior might include:

• Multiple transactions in a very short time by the same person
• Multiple failures over a longer time period by the same person
• Whether the person was previously flagged as fraud (by IP or session ID – see next step)

The amount of transactions and time frame that should trigger a fraud alert is up to you. You can attempt to gather that information by reviewing the logs after several frauds have taken place, or by attempting to guesstimate numbers that make sense to you.

8a. Suspected fraud – log the attempt and deny the transaction

With all the data we have accumulated thus far, we have decided we have a possible fraud in progress. At this point, we will show a message to the user, and log the transaction attempt for future reference (and for step 7).

Details we want to store:

• Client IP
• Proxy IP (if we found one)
• Country (and city optionally)
• Client user agent
• Client session ID (if you are using sessions – which you should, for this purpose at least)
• Transaction attempt date/time (timestamp)
• Other identifying details relevant to your service (such as user identifier if you have it)
• Transaction status (failed in this case)

Why do we store both IP and session ID? while both can be changed between transaction attempts, they can be considered as failsafes for each other. Our attacker might switch to another proxy but still use the same browser for example. It doesn’t hurt to have as many data points as possible.

The message we will show the user at this point depends on your philosophy – I suggest not mentioning “fraud” as the reason as you might scare away potential clients as well as alert the attackers that they’ve been caught. You can say the card was rejected by the bank (in the case of a credit card transaction), or that Paypal has rejected the payment. I leave the actual wording up to you.

Optionally, you might choose to manually review suspected transactions. In this case you should show a message indicating the transaction in under review and the time-frame for completion. If you do choose to manually review transactions, remember to save all the details you’ll need to complete it later, such as payment tokens or even credit-card details if you know what you’re doing (if you’re not PCI certified, I’d highly recommend against it).

In extreme cases (close to 100% certainty of fraud), we might go as far as block the payment form for the IP / session ID of the attacker, and at this point we will show a message mentioning “suspicious behavior” so that legit clients can contact us and notify us that they are not in fact attempting fraud (this has happened for us once at Binpress, and the verification process wasn’t that simple).

8b. Log and process the transaction

If we made it this far and have not reached our threshold for determining a fraud is in progress, we will try to process the transaction. Regardless of whether it was successful or not (rejected by the bank or the payment gateway), we will store it in our log for future reference (and for detecting a high volume of purchases by the same person).

The case of Paypal

We’ve mentioned one attack pattern that we haven’t fully addressed yet – usage of an hijacked Paypal account to make a payment.

While the same indicators apply, we have an additional option to confirm legit account ownership – by verifying the Paypal account Email address.

The Email address (and billing country used for one of the indicators), can be obtained before confirming the purchase via the GetExpressCheckoutDetails API operation (assuming you use the API. If you use the Buy Now buttons, you are out of luck).

This means implementing a process similar to the following:

• On the Paypal confirmation page (after user has confirmed payment in their Paypal account), we check for any of the previous indicators by getting the account details with the GetExpressCheckoutDetails API method and examining the user IP.
• If we suspect the account might be compromised, or the purchase is large enough to require more caution, we send a confirmation Email to the account Email address with a unique identifier (usually in a link back to our site). We save the identifier and Paypal payment details in our database or in the session.
• If the user opens the confirmation Email (meaning he has access to the account Email) and returns to our site with the identifier, we confirm the transaction and finish processing the payment.

Obviously, if the attacker has control of the account Email as well, he can easily bypass this method as well. If the indicators are very strong, we might consider holding such transactions for manual approval.

Note that you cannot change a Paypal account primary Email without entering one of the complete payment details (such as a credit-card or bank account numbers). Any change or addition of Email accounts to a Paypal account will notify the original Email account as well.

Something worth mentioning is that you cannot distinguish payments with a Paypal account from payments using a credit-card through the information returned by the API. This is a problem in the sense that there is no point in sending a confirmation Email to someone who used a credit-card to pay, as the Email given is the one he entered at payment (meaning he would likely have access to it).

The only indicator between a Paypal account payment and a credit-card payment is the ‘PAYERSTATUS’ parameter in the billing details returned by the GetExpressCheckoutDetails API method. A ‘Verified’ status indicates that is a Paypal account payment, while an ‘unverified’ status can be either. For this reason, we only send the verification Email to accounts that are verified, while we use more caution with ‘unverified’ accounts.

You might even consider rejecting ‘unverified’ accounts outright, just keep in mind that you won’t be able to receive credit-card payments through Paypal if you do.

Buyers remorse

The trickiest type of fraud to handle. If possible, always try to obtain proof that the user has made the transaction himself. If you ship physical goods, obtain proof of successful shipment.

For digital goods you can use try to ask for an authorization Email or a declaration of purchase (using digital signature services). Naturally, this process it not appropriate for most websites, and in that case you will most likely have to swallow the fraud as a loss.

Another factor is the originating country (if you serve an international audience). High risk countries are more likely to fall to this kind of fraud as well, which is one of the reasons many services do not accept payments from such countries.

Fraud detection services

If all of what I’ve described so far sounds like a pain, it’s because it is. If possible, I would suggest passing this information to a proven fraud detection service, and rely on their experience and expertise to increase your fraud prevention success.

A fraud detection service might be provided by your payment gateway. If not, or if you are not satisfied with it, I personally recommend the Maxmind Minfraud service. You might have noticed I’ve mentioned 2 Maxmind services here – and it’s not by accident (and no, it’s not because I was paid to promote them ).

The Minfraud service receives the information we collected thus far and provides a risk score and other data for our assessment. They use their own geolocation service to determine the location of the client (we pass them IP addresses we found), and in addition, they have a database of known proxy IPs that can be used to determine when a proxy is being used and how dangerous it is (how prone it is to be used in fraud attempts).

They use that data to compare with historical data they collected on online fraud to calculate the risk score – which is basically the chance the transaction is a fraud attempt (in percentage points).

The reason I’m advocating Maxmind so much, is that since adding Minfraud to to our payment process, we have not had one fraud slip through their checks (and we had quite a few attempts). We use it in a combination with logging and the bank security checks review to very good effect.

Bag it and tag it

So there you have it – a basic guide to knowing, detecting and preventing the most common types of online fraud. If you feel I missed something or have a question regarding something I wrote, feel free to add your thoughts in the comments.

The pricing plan he talks about is very similar to the licensing system we use in Binpress, and it’s easy to see how much of his advice can be applied to Binpress components – especially on pricing and naming licenses for different audiences.

A must read for Binpress publishers – I suggest you hop over to his blog and read his post titled “What I Learned From Increasing My Prices“.

Knowing Your Audience

There are many types of software products – games, productivity software, security products and so forth. Libraries, SDKs and other source-code products are generally categorized as developer tools.

Each category of software products appeals to a different audience and serves different needs. Developer tools are aimed, naturally, at developers (or software companies) and are more often than not a type of productivity software -  they help developers achieve more in less time.

Lets examine some common characteristics of software developers:

• They are usually very technical people. This means that if a cheaper / better / free alternative exist, they are likely aware of it.
• They know how to build software – which is what you are selling them.
• They are usually too optimistic about time estimates. That means they might be undervaluing your product.
• They are a niche audience compared to other software categories. Software developers are not a large portion of the general population (yet).

Those characteristics makes selling developer tools tough. Because of that, we need to be extra careful with how we price our products.

Impulsive vs. Planned Purchase

Buying a source-code library is very different than buying a game on the iPhone. Developers usually make the decision to purchase a source-code product after searching for free (open-source) solutions first and looking over all the alternatives (competing products).

This means that when making the decision to pay for a source-code product, the developer is already pretty committed to that decision. This is in contrast to a buying decision on the appstore where you might pick up a game that looks cool in the screenshots for 0.99$.

The reason I’m emphasizing this difference is that too often I’ve seen mobile app developers try to price their source-code products the same as they do their mobile applications, without considering the completely different audiences. Buying a source-code product is not an impulsive purchase, and the biggest decision for a prospective buyer is whether to give his credit-card details online. Once that decision is made, the actual costs become less significant.

Size of Market

I’ve mentioned that developers are a niche market. It is a large enough market that general purpose tools (IDEs for example) have a large audience, but depending on the purpose of your product, your target audience is probably significantly smaller.

If your product solves a specific problem in a specific type of application for a specific environment – that narrows down your target audience significantly.

Source-code products usually cannot hope to achieve the sort of mass-popularity that other types of software are able to reach. Considering that, we need to value each sale higher, in order to be able to generate significant revenue.

The maximum revenue we can hope to generate from our product is the price we set times the size of the market. For large markets we can always count on more customers, but for small markets we are putting a cap on the amount of revenue we generate by pricing our products too low.

Different audience types and needs

A single developer has different needs than a software company. Someone who manages a single-site has different needs than someone who manages a network of 30 sites.

To accommodate different audiences, we should present multiple pricing and licensing options that appeal to each. In our previous article, we called this tiered pricing and it serves multiple purposes:

• It creates the appearance of better value for the lower tier pricing.
• It creates the opportunity for a larger sale with the upper tier pricing. You’d be surprised how often larger companies or people with a larger budget will go for the “Premium” option, just because it’s there (they want the best version).
• It allows you to handle different licensing requirements. This is important since specific licensing details can be a deal-breaker.

This is an advice we repeat in many places on our service, and it greatly affected the licensing options we provide in the “Licensing / Pricing” step of our component creation process (must be logged-in to view).

Price Conveys Value

In the previous article on this topic, I’ve discussed the perceived value of your product – with price being a big factor. When you price a source-code product that claims to save hundreds of hours of development time the same as a meal at McDonald’s – you are sending the wrong message to would-be customers. You are making them ask the wrong questions – why is it so cheap? is the quality of code low? does it have many bugs or is not supported?

The tactic of pricing low to sell more can actually backfire and decrease sales. On the other hand, pricing a product at a healthy price conveys significant value and makes the product appear move valuable.

Software development is expensive – when we save development time we also save development costs. We should aim to keep a healthy ratio between the amount of development time saved and the price of the product. Too large or too small ratios will result in a price that does not convey the value of the product properly and in reduced sales.

Finding the Sweet Spot

In the previous article we’ve discussed the demand curve and that our goal is to find the pricing point that covers the most area and generates the most revenue.

Our goal is still the same – to find the highest price that generates the most sales. It takes some practice to get good at it, but you can get to a good starting point by considering all the factors we’ve covered:

• Buying a source-code product is not an impulsive purchase.
• Price should convey the value of the product and be proportional to the development time it saves.
• Price should take into account competing products.
• The market size / scope of the solution the product offers should be taken into account as well.
• Different pricing for different audience types.

Improving by collecting data and iterating

Once you settle on a starting point you feel comfortable with considering all those factors, you should start gathering data by measuring how it affects conversion rates (the amount of sales per visitor).

You can try and test both lower and higher prices, and see if it affects conversion. Note that when you raise prices, if conversion stays the same – you have increased your total revenue. Make sure to allow for enough data to accumulate before changing prices – and not change other parameters as well at the same time (product features, marketing content) to get reliable results.

Learning by Example

We’ve previously published a case study with one of our publishers and mentioned the pricing experiment he ran with his component with good results. We intend to publish more case studies such as this in the future to illustrate the effect pricing has on the success of source-code products.

If you have specific examples you want to read about, let us know in the comments!