For example, my company (https://circleci.com) makes Continuous-integration-as-a-service, marketed directly to developers. We have a lot of companies using us with incredible engineers (Stripe and Zencoder are 2 obvious examples who have agreed to be listed on our homepage, we have many more). Why - when they can build it themselves? Because we have built a compelling product that is much better than they could do themselves (and in many cases they tried)!
To give you one example, one customer has a test suite that takes 60 minutes on his laptop. He just pushes to Circle when he wants to test, and he gets a result in 13 minutes (blazing fast build servers, plus automatic parallelization)! That would overload a single build server, so they'd have to get a cluster set up. That sounds like fun , but only for the first hour.
(and is there support for not github based hosting?)
[edit] And I see that you dont support ghc (haskell). Oh well, I guess I still need to wait for Travis CI to roll out there paid version :)
We don't support non-GitHub sorry.
We do support ghc, and have a few customers using it. I should write a doc for that.
Also, frictionless CI as a service? You are doing God's work. I hope you succeed.
1) does that give a path towards users providing their own *.deb bundles and thus being able to use their own choice in compiler versions?
2) part 1 is a bit important, I may be doing a lot of dev work against ghc head (or patched versions thereof) in the coming months (though not for another 2-4 months realistically), and unless i can a la carte plug in the ghc version I want, i may a well roll my own thing on top of jenkins and the like :)
In my experience, there is money to be made in that market, I've worked for companies that paid big money for crap like ClearCase, after all. But in these cases the product was basically forced on the developers from IT/management/other departments.
So, yeah, there is money to be made in this market, but in most cases you'll have to be prepared to go through the old fashioned good ol' boy sales model. Trying to sell directly to developers is a very, very difficult road.
(a) they raise funding
(b) or they have some revenue or profitability
(c) or they work for BigCo or at funded start-up
In situations (a), (b), (c), my observation is that developers are not afraid to fork out $10-$100 per SaaS service.
Your point to sell to marketing/product etc. hold holds true and I would agree 100% from experience. At the last start-up I worked at, it was the Product people that would regularly find cute little SaaS tools to fill holes. It goes without saying that most SaaS tools should not be made with the stereotypical hardcore dev in mind but rather with product/marketing/sales in mind just as much.
If your service is only $10/dev/mo, figure out a way to make it worth more, or raise prices, or figure out a way to never have a support call. Support on that will kill several months worth of profit, per response.
That said, I can tell you that at least for a start-up, crossing a certain threshold can mean the difference between just being able to purchase the tool or needing your boss' approval. For the last start-up I worked at, the treshold was closer to $50 or so. We wouldn't think twice about tools in that vicinity. Soon as it crossed the $100 mark, we'd need the CEO's okay. My feeling is the upper limit on that shifts greatly depending on the different segments within enterprise but that is my one data point.
Of course, all of those are more likely to drive adoption of the SaaS tool if it helps drive revenue or increase costs. aka If someone can pay $1 to avoid $100 of work or earn an extra $100, then the odds are in the SaaS tool's favor.
(Granted, I am biased as I work for Twilio but I also built SMS systems long before I joined last year.)
The former, like most other professionals, will gladly pay for services and products that make their business lives better. And yes, while there will always be a small (and vocal) subset of professional developers who absolutely must write their own time tracking software, the overwhelming majority will just pay for something like Freckle. It just doesn't make any economic sense to write their own.
As someone who sells three products (a SaaS, a book, and a workshop) for consultants - mainly web developers - I can tell you first hand that the biggest win for targeting this audience is that they're easier to find and sell to. Getting, say, general contractors to find your product seems complicated and pricey. Developers, on the other hand, can be an inexpensive traffic source if you're doing the right things (like writing targeted content that gets indexed and shared.)
I'm very concious of what it costs to develop and maintain software and the risk that is entailed, never mind the operational costs of running production systems.
I aim for commercial success by having systems that, in some respect, are at least an order of magnitude (if not two, three or four) better than the status quo, but I've got a lot of respect for companies that can serve my everyday operational needs at a fraction of the cost of doing things myself.
Looking at your profile, it seems like you're speaking from experience. Have you found that selling to marketing and sales folks was more effective for your own business?
Otherwise, your best bet for getting developers to buy things is to try and sell them stuff that would be boring for them to build. Most developers I know would find it very interesting to build something with machine learning or to re-architect a system several times over for scale. Not many of them would like to spend time building something better than textmate.
The problem with being a developer building for developers is that if you are interested in working on a problem your customer probably is too. People would prefer to pay you to take out the garbage.
Our experiences have been the total opposite, we've had developers discover our tools, test them out, and then championing them inside their company, resulting in sales for us.
The difference in our case is that we're doing a lot of the boring must-have plumbing for online games such as registration and authentication, integration with payment providers, cloud storage, multiplayer messaging, etc, and we leave all the fun parts of game development to the developers we are selling to.
Check it out: http://player.io (Shameless plug, sorry. :) )
Developers in good companies are increasingly able to affect technology decisions and purchases. Senior developers in team leading roles have (small) budgets and can quite easily approve $x00 a month subscription. And there are more and more people in management roles who started as developers.
Of course, the old world of direct sales to top management is still going on strong, but if there are macrotrends to jump into, the one that predicts that developers have bigger budgets and even more decision more power in the future is a pretty sure bet.