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!

Component page overhaul

We’ve reworked the component page look-and-feel to match the new theme we’ve had in the homepage for a while now. In addition to visual changes, we’ve added several new features:

• Visitors can now create feature requests and engage in discussion about it with the developer and other visitors. We’ve noticed similar discussion going on in the comments and wanted to provide a better platform to do so.
• Issues can now be accessed directly from the component profile, in order to be access in context and to encourage using tickets instead of comments to report problems.
• User reviews have been expanded to show more information, including a breakdown of review scores.
• Publishers can now migrate comments to either issues or feature requests – use this option to clean up your comments.

Github integration

We’ve integrated Github into our flow for a while now, but haven’t officially announced it here on the blog. Users can register and log-in using their Github account, and publish existing Github repositories as components directly.

We are big fans of Github and feel our services greatly complement each other, as we provide the commercial layer over Github code-sharing and versioining service. We hope to see many more Github users publish their code on Binpress as well.

Licensing changes

We’ve revised our licensing to better accommodate compiled binary distribution (ie, components for compiled application development), and to simplify some of the terms and wordings to help visitors understand better the difference between the various licensing options.

Publishers now have more control on how their components can be used, and users should have an easier time understanding what are the rights and limitations granted by each license. If you are a publisher, you should go over your existing licenses and see if there’s anything you would like to change.

Binpress API Beta

We’ve released an early version of our API, which mainly deals with component data. Visit the API reference page to get started, and send us comments and suggestions on what you would like added to the API.

Keep in mind that since the API is in beta, you might experience some issues (though we did test it thoroughly). If you are encountering any issues, please let us know.

Find something out of order? let us know!

We QA everything and then we QA it some more. Yet, we’re certain some things slipped through the cracks as it’s unavoidable. If you find something is not working as it should, please let us know and we’ll take care of it.

The success of our components varies widely, from high-volume selling / downloaded components to relative unknowns. The amount of sales / downloads a component generates is a factor of both the traffic it gets and how well that traffic is being converted to a purchase / download.

We’ve previously covered several ways in which you can get your component noticed and generate additional traffic to it (and we’ll be revisiting it soon), and this time I’d like to attack the other part of the equation – converting your component traffic into goal completions (either a purchase or a download).

So what can you do to improve your components performance?

Retouching component content

Re-read all of your component content, starting with the summary and description. Does it make sense? does it convey what need your component is helping and how it does it? good component content should obey the following criteria:

• Readable – content should be easy to read all the way through. Good grammar is a must, and try to avoid overly technical jargon. Try to think how it looks to someone without your specific expertise (but a developer still).
• Concise – Get to the point as early as possible. You might be losing you audience with a long introduction and lengthy explanations that are not needed and could be confusing readers. Summarizing features in a bullet list helps. Add headings between large blocks of text and make your text easily scanable.
• Comprehensive – while it seems contradictory to the previous point, make sure you touch upon all the important points your component addresses. Structure your content in a way that allows readers to quickly understand what it does, and then supply additional content if they are still interested and want to read more.
• Well-formatted – Use the markdown syntax (explained in the content editing pages) to better format your content. Use headings where needed, use bold and italic effects to highlight specific text and add bullet lists for quick summary of points. Don’t forget to properly indent your code so it will appear formatted in the content page.

Keep in mind the summary appears in all component listings and on our affiliate widget – use that text to convey very quickly the essence of what your component does. Don’t forget to mention important keywords readers are looking for, such as programming language and relevant frameworks / platforms.

If your component has a visual aspect such as a UI, adding high-quality screenshots really helps readers understand what they’re getting. Adding a nice thumbnail helps your component stand out and be more distinctive in component listings.

Reworking the pricing scheme

We’ve written at length about how pricing affects the success of a software product and you should go over it if you haven’t already, but I’ll repeat the basic ideas -

• Pricing matters
• For any software product there is a range of pricing that within it conversion is optimal.
• Pricing should reflect the perceived value of the product.

Pricing your own work is very difficult, in every field. Especially so with source-code components, for which the market is young and mostly unknown. Lowering or increasing the price could have a substantial effect how well you sell – you should read the aforementioned article for more details.

Make incremental adjustment to your component pricing and see how it affects conversion. Make sure to give enough time for data to accumulate and become significant.

Engage your audience in the comments

It’s no surprise that our top publishers are very active on the comments section of their components. Engaging interested visitors can both lead to a direct conversion (by convincing them your component is what they need), or to a future conversion as it both provides more information and shows your professionalism.

Make sure to respond in a courteous manner to comments visitors leave on your component page. You can answer concerns they may have and those comments are there for future readers that might have the same questions.

Use the comments to improve your component content – if a question is repeatedly asked, make sure it is well answered in the component description. If people are looking for a certain feature which is currently missing, consider adding it to the component.

When in doubt, ask us

Not sure how to go about changing the content or pricing? if you want to run something by us or just ask a few questions, you can always use the admin feedback section that you went through when you got your component approved. We try to be as available as possible and set you in the right direction.

First of all, I would like to thank everyone who participated, we had many great entries and our judges had their work cut out for them deciding on the best ones.

3rd place award:

Our 3rd place prize goes to Kemal Taskin with RadioTunes SDK for iOS – a radio streaming engine with support for the http and mms protocols. One of our judges wrote:

Compared with the other components this is one that provides the greatest value to a developer because of the complexity of interfacing with FFmpeg.

The 3rd place award is a package worth over 3,500$, including 500$ in cash.

Runner-up award:

Our runner-up award goes to Yaroslav Sivokhin with AsyncMVP – an asynchronous message-based module system base on an MVP template for the android platform. The judges really liked this one -

For me this project is a highlight, since although it seems to be in an early stage of development, turns Android application development on its head and introduces modern programming paradigms that have proven successful for years to the Android world. It’s a bold move into a completely new direction of Android app development, and I’m excited to see where this is going.

The runner-up award is a package worth close to 6,000$, including 1,000$ in cash.

Grand prize winner:

Our grand prize goes to Nick Lockwood with iCarousel. iCarousel is a simple, highly customizable, data-driven 3D carousel view for both iOS and Mac OS. Quoting one of the judges:

This is a really great submission – it provides a unique UI element that is highly customizable and looks really good. The code is great, very easy to understand and use, and aligns with many iOS design patterns.

The grand prize award is a huge package worth close to 11,500$, including 1,500$ in cash.

Thanks again to all the participants and the judges who helped us make this contest a success and our great sponsors who made this contest possible. Specifically, we would like to thank Amazon AWS, Tropo and Appsfire for their significant contributions and our other sponsors. We look forward to continuing this tradition and bring you great prizes for the best contributions of source-code.

Java lists in real world applications

It started with large numbers of large lists – people, equipment, payments, jobs, work orders,… the usual – and a program that had to juggle them all. At any given time, most of the lists might be very small or empty, while some would be huge. While the program ran, many of the lists would yo-yo dramatically in size, putting a severe strain on memory management. Of course, the idea was to handle as much data as possible with the best performance possible for whatever machine it happened to run on.

Choosing the Data Structure

What to use? To start with, kindness to garbage collectors (and the resulting garbage-collectors-kindness-to-programmer) required some form of linked list or other linked data structure.

Why Not Arrays?

Originally, I rejected arrays (and Java collections framework structures that use them, such as ArrayList) because I needed to do a lot of inserts and deletes, which meant shifting data inside the arrays and continually reallocating space for the arrays, larger and smaller. With today’s hardware and operating systems, these concerns are not valid; by my tests, array operations are fast beyond belief.

Not valid, that is, in a simple program. Mine would be resizing the lists at a furious pace, leading to lots of memory reallocations, leading in turn to serious memory fragmentation. (Note that the standard sort on an array – or any other Java Collection – generates a temporary array the same size as the original, making it as bad as resizing.) When the garbage collector needs space for a large array and memory is fragmented, it has to move existing objects around to create the large contiguous space.

Put simply, large arrays can cause a program to slow down dramatically, even when most of the available memory is free. Also, if the GC cannot create the space fast enough it will throw an out-of-memory exception. (I always wished it would take another quarter second, recover the space, and keep going, but, really, the exception is much kinder than a program that does nothing while using 100% of CPU.) Put even more simply, there is an innate performance problem with arrays for this sort of work; modern technology has merely converted it from slow performance into an occasional blow-up. At the end of the day – old tech, modern tech, future tech – I needed a structure with links and small elements.

Required Performance

The program I was writing had performance requirements beyond the obvious “run real fast”. It was to work with a graphical user interface, which meant some aspects mattered more than others. The user needed to see immediate results from his mouse and keyboard actions. With the program pushed to its limits, a bit of sluggishness could be tolerated, indicating only the need for less data, simpler data, or a faster computer with more memory. But noticeable delays (half a second or more) had to be avoided.

While this was a business program, users would want, and be getting, fast answers and it would have the feel of a real-time game. (Or of a word processor when you have three minutes to write a long memo. You do not want to see that hourglass!) Overall speed did matter, but keeping the worst-case performance unnoticeable was critical.

The Requirements

All the lists would be maintained in sorted order and might need to be accessed by their sort key. This suggested a binary tree for quick finds. (Hash tables use arrays, and do not work for finds along the lines of “find the first entry with a start date on or after January 1, 2012.” Either problem was and is a show-stopper.) At this point, Java’s TreeMap looked like a good bet.

However, most of these lists could optionally appear in display tables (JTables), and this meant indexed access was needed. Using two TreeMaps does work, but the binary tree link structure is identical for the sort keys and the index numbers. With my own binary tree I only needed to allow the search key to be determined immediately before doing the search. Then interlaced index and key searches could be done with no loss of efficiency. (On one search we look at dates as the “key”, and on the next, indexes.) And so creating SortedList began to look like a good idea.

When adding and removing rows from a list, the index numbers on each row would have to be incremented/decremented by moving sequentially through the list from the add/delete point. With a normal binary tree, this means locating the row inside the tree with a search and maintaining a list of parent nodes in the tree during the sequential movement. But searches are expensive and I already had the row! What I needed now was just a basic linked list. I had one entry – all I needed was the next one. And I needed it fast, because I might have 100,000 rows to update without troubling the user with a delay.

The Threaded Tree to the Rescue

Fortunately, an oddity from my college days percolated up into my consciousness – the threaded tree. To thread a binary tree, null references in the leaf entries are set to the logical next or previous entries. (Okay, it’s not quite that simple; look it up on Wikipedia.) Now my binary tree was also a linked list. Given the row I was deleting (or adding before), I had immediate, fast access to the next one. Problem solved, and SortedList looked like an even better idea..

On to the next problem: many of my lists were sorted, or could be sorted, by time. The rows contained jobs with start and end dates. I needed to know which was happening at a particular time. (The time spans did not overlap, usually.) This meant finding the first relevant row (one whose start date was on or before the particular time) with a search on time, then scooping up the rest with sequential reads. Here, my threaded binary tree started really earning its keep. And it had the additional benefit that it was easier just to move back and forth in the linked-list-tree than it was to read rows from the tree, put them somewhere else, and work on them there.

Concurrent Modification

I moved further away from TreeMap when I wanted to control when the number jobs (rows) worked rather than just finding out who was working when. This meant removing the job from the list completely, changing the dates, and adding it back in. Modifying a TreeMap, or most any other Java Collections Framework class, causes an iterator to throw a ConcurrentModificationException. This is normally a good idea, and this feature has saved me a lot of grief – but in this case it would mean redundant (I already have the current entry!) finds to recreate the iterator every time I moved a job.

(I have written several classes extending java.util.Collection. They all do other things the standard classes do not, but I have used each of them many times only because I needed to delete and add elements while stepping through the collection with an iterator. I do have to be careful.)

Other Uses

The ability to use different key values with the same sort, like with indexes and sort keys, proved useful in other cases. I had to work with numeric dates where only time (days, for instance) on week days was counted. So if Friday was 123, the following Monday would be number 124. Of course, they would also be numbered using all days, with Friday being, perhaps 152 and Monday 155. Both dates sorted the same way, but I needed a different key depending on whether I was looking for day 152 or weekday number 152. I also created an almost identical class to track selections in a large table, where I needed to search both on the row number within the table and the row number within the selection. (I was surprised to find row numbers and dates were so similar.)

Design Problems

A Balancing Act

A binary tree must be kept balanced or it becomes horribly inefficient, a sort of singly-linked list with the links going the wrong way. One big advantage to a threaded tree is that it can be balanced very quickly, so my approach, right from the start, was to rebalance when needed, as opposed to, say, using a red/black tree.

This was done by counting the levels whenever searching the tree, whether for adds or reads. Down too many levels? Rebalance. This has the advantage that the tree can become very unbalanced indeed without triggering a rebalancing until it matters. (Balancing is fast, but it does take some time.) Now, if a million rows can be added without rebalancing – more on this in a moment – they will get added very fast. Any attempt to read, add, or delete a row deep in the tree will trigger a single rebalance, which should keep the tree efficient for some time.

There was a problem here, however. Should one do a lot of adds, the tree can become somewhat unbalanced, if not quite enough so to trigger a balancing. If the next phase of use involved extensive queries, one would want the tree to be as balanced as possible. To provide peak performance in this situation, I added a “balance” method. Calling this method says, essentially, “We’re done adding. Prepare to do a lot of fast queries.”

Sometimes the query phase is done with multiple threads. As the structure ought to be immutable – none of the internal should references change – this should not to be a problem. But what if a query triggered a balancing? Before, we called the balance method because we were afraid it would not be called. Now we need to call it because it might. Should another query come through during the balancing, via a second thread, things will get ugly. But once “balance” is called, the tree is immutable and multi-threaded querying can begin.

The next problem hit while working with real data (or at any rate, data invented by someone else, not me). It resulted from massive adds. There was no reason the million rows from the database should be in sorted order since I had not asked for any order, but in sorted order they were. (Since then I’ve found data is almost always ordered. It’s just the natural perversity of the universe.) My tree, following tradition, added new entries as leaf nodes, which would have worked really well if the order had been random. As it was, I was rebalancing after every 24 or so adds. Filling my tree took forever. (1 rebalance is unnoticeable. 50,000 rebalancings are noticeable.)

I solved this by adding new entries as high in the structure as possible. Now, if the data was already completely sorted, the tree would end up, very quickly, as a simple linked list with each new add placed right at the start. It was a horrible tree, perhaps, but the first time a good tree was needed, a single balancing would put it right. My tests show SortedList now sorts ordered data ten times faster than TreeMap.

Data is always ordered, except when it can embarrass me by being random. Now, random adds could trigger repeated balancing – embarrassing. (The problem was rarely anywhere near as bad as the ordered data problem, but it was plenty bad enough.) I fixed this by shifting the add points closer to the leaves with each rebalancing, so the more random the data, the closer it would come to the traditional, add-new-entries-as-leaf-nodes method. My tests show SortedList now resorts random data almost as fast as TreeMap.

Essentially, SortedList now takes advantage of any order existing in the data rather than suffering from it and reverts gradually to traditional binary tree adds if there is no order. SortedList’s speed now ranges smoothly from very fast with sorted data to not bad at all with random data.

Relativity and TreeMap

So how does SortedList compare with TreeMap, time wise? (Time is not the only consideration, but it is interesting.) As noted above, both take about the same time for random adds. With presorted data, TreeMap speeds up two to three times, and SortedList is yet ten times faster than TreeMap. When updating indexes, a sequential operation, SortedList is more than eight times faster than TreeMap. For the rest, TreeMap takes the lead; it can do finds and deletes in almost half the time it takes SortedList.

The rapid renumbering on rows and the ability to sort almost-ordered data quickly allow large, sorted display lists to be modified without the user being aware of any delay. So these tradeoffs let SortedList manage JTables and other displays with large row counts.

(SortedList has twice as many pointers to maintain as TreeMap, so the slower deletes are to be expected. I am not sure why SortedList’s finds are slower; I intend to look into that further. I am not sure why the two are comparable in random adds. The extra pointers ought to hurt SortedList there. I suspect TreeMap is slowed by the extra work required by its Red/Black tree. SortedList, on the other hand, does simple adds and lets the randomness of the data keep its tree balanced.)

Internal Versus External Linkage

SortedList is internally linked, unlike the classes in the collections framework. This means:

• Entries must extend a special class, SortedListNode. (Not too bad.)
• An entry could only be in one SortedList at a time. (A definite minus.)
• No iterator is needed. (A plus.)
• If I had an entry, I could always get the next (or the previous) fast. (A big plus.)

It gave me what I needed for high performance.

However, sometimes the objects I wanted to put in the tree could not extend SortedListNode, and sometimes the objects needed to go into more than one tree. I needed a bit more.

Using SortedList, I created TTreeMap. It implements java.util.Map, and can replace java.util.TreeMap. Beyond the Map interface, TreeMap has different – and in my opinion, better – methods, but it does the same job, and more. To recreate the ability to find an entry, then read through the list sequentially, I wrote a find method that returns a ListIterator. This is positioned on the found entry and allows high speed sequential moves in either direction.

And so, SortedList

a threaded binary tree and a “map” or “dictionary” associating key-value pairs. It seriously outperforms in key areas, has some unique abilities, and it is otherwise competitive with everything else available:

• High speed sequential reads, in both directions, and starting with any entry to which you have a reference.
• High speed adds of ordered or reverse-ordered data.
• Concurrent access: you can add to or remove from the list without losing track of your current entry, or current entries.
• Find an entry by key, then move through the list in either way, reversing direction as desired.

More generally,

• Works well for managing data in JTables.
• Superb for sparse arrays, particularly where the data in near-by elements tend to overlap and the code needs to look around to get a good sense of the situation.

And there you have it. I published the finished SortedList on Binpress for commercial use, as that it was its intended for. I’ll be glad to answer any questions or comments, so let me know what you think!

Want to write a guest post on the Binpress blog? get in touch and let us know!

We can feel mobile components picking up steam in recent months, and we want to reward you guys for your efforts. Note that you can also submit previously approved mobile components by tagging it with the contest tag and letting us know in the component review comments.

Homepage and browse page redesign

On a side note, we recently launched a redesign of the homepage and browse page. The homepage now showcases featured components as well as several new segments, and the browse page features a new filtering and browsing interaction. We are already noticing an uptake in sales as a result, and will be looking to improve on it more in the coming weeks. Check it out and let us know what you think!

It has been very tiring but worth it, we connected with a lot of people who hopefully will help us make Binpress bigger and better. Our belief that Binpress is going to be huge real soon has never been stronger – watch this space for further developments.

Mobile Programming Contest

As we’ve mentioned before, our mobile contest is coming up (if you didn’t hear about our previous event, check it out here). Several big-name sponsors have signed up during TC disrupt, and they’re going to make fantastic additions to a very strong line-up.

Expect extra awesome prizes for the winners, so if you have a good idea for a mobile app component – you should get started now! we will allow multiple entries from the same developer, so you can multiple prizes as well. Everything submitted before the contest starts will be eligible as well, so get started early to make sure you pass the review process.

More exciting updates will follow later this month, stay tuned!

Supercharged Mobile Development Contest

As we mentioned in our latest newsletter, we have a massive mobile development contest coming up. We had a programming contest when we first launched, which was a major success, and we are looking to start a tradition of contests to inject some competitive spirit and awesome prizes for our community.

The theme this time will be mobile development – with prizes going for the best submissions of a component for a mobile platform (iOS, Android, Windows Phone). We have some huge sponsors from the mobile development world providing relevant and worthy prizes.

The contest is scheduled to start on Sept. 14th, so stay tuned for more concrete information real soon. Keep in mind that any mobile component you’ve previously submitted and got approved will be eligible to participate.

Binpress in the valley

Binpress’ founders, Eran and Adam, will be attending TechCrunch Disrupt, representing Binpress (not as one of the contestants though). They will also be expanding our reach by meeting with strategic partners and investors during a 3 weeks tour around the valley. Look forward to big news in the coming months!

Since our capacity at the Binpress offices will be going down somewhat, please bear with us and be patient with contact forms and component reviews. We are on top of things, we just might take a bit longer than usual to get back to you.

Homepage redesign

A redesign of the homepage is in the works, which will give several benefits to component authors:

• Components will be shown in chronological order, giving a better chance for newer components to get noticed.
• A featured section in the homepage will put the spotlight on different components each time. Getting featured will be based on visitor response to the component – more on that soon.
• Streamlined navigation and discovery interaction for allowing more components to gain visibility.
• A new special section will be featured on the homepage as well (more details soon!).

This is good news for components that do not receive significant organic traffic. We plan to reward loyal component authors who we believe should be selling more given the right exposure.

The first step should be to check out our idea suggestion section. This is where actual buyers from the Binpress community can request components they need and are willing to pay for. I used it to request a Tag cloud generator for PHP, which I bought as soon as it was ready after a quick revision request from it’s author, Andrius Virbicianskas. I will be posting a case study about this component in the near future, make sure to subscribe to be notified when it’s published.

Q&A sites and forums

A simple way to get ideas for components is to visit Q&A sites (such as StackOverflow) and forums and see what common problems people are having. Search for common issues or help requests with implementing features in the languages and frameworks you like to use, and you could easily find good ideas for needed components. When you find an idea you think has demand, do a little research on other sites and on google to estimate its potential (as we’ve discussed in our previous post).

Variations on popular projects

My next suggestion is browsing through plugin repositories of popular frameworks or platforms (WordPress plug-ins, jQuery Plugins and Github for example).

Popular existing projects could be a great starting point for a good component since you already know that demand exists for it and you can leverage its popularity by mentioning it in your product description or name. Common ways to create something new from an existing project are to provide missing or requested functionality (check what people are saying about it) or porting it to another language / framework / platform.

This last tip could also work with our own inventory. We encourage you to explore less populated sections of Binpress by platform, language or framework, and get ideas for components you can port to your own environment. You should also go over your component idea and see that it’s not already published on Binpress, since we try to avoid having components with duplicate functionality.

Going through your old libraries

Another way to find ideas is to revisit the source code of old projects, and look for reusable parts you can extract that might work as standalone product. We had an excellent post about doing just that called Extracting code from old projects.

We’d love to hear about your own sources for inspiration, and if you published on our platform before (or sold any software products actually) we’d love to hear about how you came up with your idea. Please share with us in the comments!

We wrote this post mainly for our developer, but it should apply to anyone selling digital products – from PC Software to iPhone apps.

Step 1: Estimating value and need

The first thing you need to evaluate is whether there’s a need for your component, and whether it is worth the price you’re asking for it. In order to do that, ask yourself the following questions:

1. Is my component solving a real and significant problem?
2. How hard is it to develop this component from scratch? there’s a certain barrier between willing to do something yourself and paying someone else to do it. Does your component cross that barrier?
3. How big is the demand? are many developers asking questions about the problem this component solves? is the functionality appearing in a lot of websites or apps lately? (more on how to determine this in a bit).
4. Are there any additional benefits to buying the component compared to developing it from scratch other than saving time? (domain expertise, insider knowledge)
5. How often did you use your code in your projects? how stable / mature is the solution?

Answering those questions will give a general idea of what how attractive this component would be for potential buyers.

Step two: Assessing demand through Google

The second thing you need to do is evaluate the demand for your solution. There’s a very simple way to do this, and I’m going to show you exactly how.

A. Come up with a few keywords or phrases that people might search on Google and expect to find your component.

One way to do so is to think of a general way to describe what your component does (for example “Image resize” or “scaling images”), appending the language, framework or platform you are writing for (for example “javascript image resize” or “jquery image scaling”.

Another idea could be using the name of a product your component might be replacing or complementing (for example “magento tax plugin”).

B. Go into Google’s free keyword tool and add these keywords into the box.

C. Go over the results and look for the Global Monthly Searches. If there are no searches for none of your keywords, try to come up with others (you can use Google’s suggestions) and repeat the process before giving up.

D. While you’re there, take note of the rest of the related keywords that Google is suggesting to you, as it is recommended you add them to your description or even consider them, when naming your component.

E. Look at the competition level. If there’s a lot of competition for your keywords – which is a good sign which usually indicates demand – it is recommended that you run a search on Google and research your competition, so that you can make sure your component offers something unique or some sort of angle that the other doesn’t, whether it is a unique feature, easier implementation or a lower price.

While Google’s estimate is not always accurate and does not reflect the actual number of people who really need this solution, it does indicate if there’s a demand for you solution. Binpress is highly optimized for search engines, so you can assume your component will be visible to most Google users who are searching for the relevant terms.

Bonus step: Stack Overflow & Twitter

Another good way to determine the demand and need for your solution, is to search online communities where developers hang out – such as Stack Overflow and Twitter.

Search Stack Overflow – How often does this problem come up? How many developers are struggling with it?
Try to think of all the possible of ways people might describe the problem your component is solving, and as many keywords as you can think of that people might use to search for a solution to that problem. You could do the same with Twitter if you need more info.

Using research to improve your chances

You can use the results of your research to improve your component – by adding much requested features or improving the description to cover the problems people are looking to solve.

To sum up, these methods should help you determine whether your component has a chance to generate any sales on Binpress. This is not to say that if there’s no demand you shouldn’t code or publish your idea – there are always surprises, and sometimes people don’t know a solution might exist until they see it. As a starting point though, it is always good to think about where your potential buyers are coming from rather than hoping to be the exception.

Got additional advice or questions about those techniques? let us know in the comments!