Most web developers I know share a common story. They start out developing websites for people in order to pay the bills, but after a while of churning sites out, they start to see themselves repeatedly solving the same problems. So they package things up into libraries and frameworks to make their lives a little easier. Eventually these projects start to get a life of their own, and at some point the developer thinks it reaches a level of maturity where it's worth making these available for the world, perhaps trying to make some money in the process. Most the time people overvalue their own creations, and this is especially true with code, but if those who manage to really deliver people something they're actually looking for might be able to shift from being a website developer to being a Micro ISV. Running a product based software business is still hard work though. Beyond just developing the software, you've got to worry about things like setting up sales channels, marketing, etc. And with software, you've got to deal with things like code compatibility and support. It's a steep hill to climb.

This brings me to Concrete5 and the reason for this post. Part of the genius of concrete that sometimes gets often overlooked in reviews is how extensible it is. Franz (concrete5's CEO) uses the metaphor of Legos, where different components can just plug right in. Yes, some other frameworks have tons of plug-ins, but they're typically not nearly as thought out, with the ability to integrate as deeply into the system or override a package's default behavior. And when it only take a few minutes to purchase and install something that would normally take days or weeks to develop, it clearly makes sense to pay a little for concrete5 packages. Over the past year or so I've done a lot of work on the marketplace, including making it so that developers can submit their own packages, have them reviewed, and track their sales. My hope was that by opening up the marketplace it would give developers more ownership in concrete, leading to crowd-sourcing some of the development, plus it allowed me to start submitting some of my packages, beyond the ones I've made when working for concrete. So like what Apple has done with the app store, concrete has a foundation for developers to sell their work, which allows them to just concentrate on developing and supporting their products. And it turns out that the economics work. People are willing to pay for packages that solve problems and saves time. While it may take a few months of sales to pay for the upfront time involved in developing packages, over time it does generate some solid recurring revenue that makes it well worth while. I don't want to give the impression that this is the best way to get rich, because I'm still probably not making my full hourly rate off of the time that I've invested, but it is rewarding nonetheless. It's a good feeling to see hundreds of websites running components that you've developed. Plus it does also lead to additional paid work too, provided you take the time to develop relationships with your customers.

But this has been a learning process for sure, and can be a bit overwhelming when clients don't realize everything you're trying to juggle at once. So for some of the other concrete5 developers out there, I thought I'd pass along a few of the things I've learned about the process:

Find a niche compared to a lot of other software projects, concrete's customer base isn't huge, so think about both the supply and demand for the solution you want to provide. Does it meet a need that you see people having trouble with in the forums? Are there other packages that already address the issue? If you're going to compete with an existing package in the marketplace, do it for the right reasons. If you think you can solve the problem in a better way, that's cool, but don't reinvent the wheel and cannibalize the work of other developers. It's best to come up with something unique, because the last thing the marketplace needs is another photo gallery (although that's certainly a good way to start learning how to make packages). There's definitely still a lot of unmet needs waiting to be filled. A lot of packages start off as paid extensions to clients' sites. This makes sense because you've already covered most of the cost, and you know it's something that someone might be willing to pay for (make sure you work out who owns the rights before doing so though).

Take the time to polish People have pretty high expectations with software these days, so it's worth taking the time to polish your work after the main functionality is in place. While the marketplace peer review process can be a bit frustrating sometimes, it helps ensure that the packages that do get released are of a high standard. This works out well for everyone, since customers will know they're not paying for crap, and will lead to future sales from the marketplace if their experiences are positive ones. The first impressions that people have of your packages tend to last though, especially when the first people who buy it may also be the first to give you reviews. So don't submit something that's only half finished. Design your packages with flexibility in mind, and try to anticipate some of the various ways people are going to try to customize them, or ways that they might break them. Give your css unique class and id names, so that they won't conflict with core or theme css, and to make the work of designers who have to tweak it a little bit easier. Think in terms of offering nice user experience for people that are less technically inclined, because the more work who do here, the less support requests you'll get later on, and it'll help out the marketplace review team too if you take care of the glaring problems before you submit.

Pricing I wish that people would approach the marketplace thinking "how much would it cost if I paid someone to develop this", because if that were the case they'd realize that they're getting a pretty good deal. But people tend to be pretty price sensitive with this stuff, and unfortunately the web has established this unrealistic expectation that everything should be free. Charging for your time is the fair thing to do though, particularly once you realize what kind of support people expect to receive. It means that you'll be able to afford spending more time on further development, and it'll help push the quality of concrete's add-ons higher than those on competing platforms. Something that I've noticed watching how the photography industry's been changing is that we've entered an age of micro-payments. With global competition and tightening budgets, it's driving down the price of software. For example, earlier versions of concrete use to sell for $50k for a license, and now it's free. But at the same time the customer base is increasing. People are getting more comfortable spending money for apps, particularly with the popularity of iphone/ipad apps. The optimum price for packages can really vary, but you should be asking yourself questions like: What kind of competition does it have (from other packages and other 3rd party solutions)? What's your target audience, and what are they willing to pay (personal websites or businesses)? Will the package pay for itself (ecommerce related for example)? How long did it take to develop and how large a problem does it solve? And the big one is how much support is it going to take? The price you set for each package largely depends on your motivations for releasing it. Are you just giving back to the community, or trying to make a profit? If you're going for the latter, then there's a lot of guess work here, but I've done some experimenting raising and lowering prices, and I've found that a few packages end up selling and making more after lowering the price. Others definitely deserve a higher price because of their complexity. If you're hoping to get paid a fair rate for your time, then you're shooting for that sweet spot that maximizes revenue.

Supporting your product is half the work There's a curve here, with a lot of bugs and feature requests up front, but if you stay on top of these they trail off over time. If you release buggy code, this will dilute any profits you were hoping to make from sales, so take the time to test and be patient with the review process, because it will save you a lot of pain in the long run. And poor support not only hurts any future sales from that person, but it'll make them less likely to buy other packages in the future too. With some people that are having severe issues, I often offer to debug it on directly on their sites if they send me their FTP and CMS login info. This hurts because of the time involved, but it's good to get bugs taken care of so you don't have to deal with them again in the future. On the other hand, there are some people that just demand too much time, often trying to get the package to do something that it just wasn't designed to do. So there are times that I'll just offer a refund or offer to charge hourly to help out. If you get too overloaded and find that you're not able to stay on top of peoples' support requests, the best way to ween down their number is to just raise your prices.

Follow the 80-20 Rule: You can't please everybody, so shoot to include the most important features in your packages. If you let things become too complex, it'll take too much time to make it worth your while, so focus on the core feature set of what you know people really need. If you've got multiple people requesting the same features, that's probably something that should be included. For those people who are urgently looking for a feature that's not going to make it into your packages anytime soon, you can tactfully offer to do it if their willing to pay for the time that it would take. If it's something that's going to make it into the final package and it's something I was hoping to eventually add anyway, I often bill at a reduced hourly rate, since everyone is benefiting from the new feature anyway. I've also done whole packages this way, where someone pays me to develop it for them at a discount, but I keep the rights to resell it in the marketplace. Paypal makes invoicing for this kind of thing relatively painless. I recommend asking for 50% down from people though, just so you know they're legit.

Develop Karma concrete5.org has a cool karma system, and you might get a free t-shirt or something if you score high there, but it's about more than that. It makes sense for concrete5 developers to collectively contribute in growing the community, and to help people out in the forums when they get stuck. Now and then they might even click through to your profile to check out your other work & packages. And taking the time to build a reputation for being knowledgeable, producing solid code, and giving quality support does lead to some additional sales and more offers for hourly work.

You've still got to promote I'm a bit hesitant to write this, because to go too far in the other direction is to be a spammer (which will have the opposite effect than what you want). But there's more that can be done than to just adding something to the marketplace and hope your work gets found. With more stuff being added there every week, it's going to get increasingly difficult to get noticed there over time. So keep an eye on the c5 forums and twitter, and post a reply if your packages might be what people are looking for. Take the time to create an add-ons pages on your website, linking each to the marketplace, and with some unique content so it'll help with search engine rankings. Keep each page targeted, with meta descriptions. Get the word out when you've released new major versions. It's also cost effective to take out targeted google ads for some packages, since the conversion rate for packages tends to be a lot higher than most types of advertising. Having screencasts and demos of your packages boosts sales somewhat too (maybe by about 20-30%?).

If you have some additional thoughts or tips on your experience with the marketplace or developing concrete5 packages, I'd love to hear them if you want to comment below.