Nope, I totally disagree. Developers hate paying for things and love to build things themselves. There are a few successes, like GitHub, but they are outliers and on the whole developers are a terrible group to try to sell into. Your best bet at getting a developer product to succeed is to sell the tool to someone in another role (product, marketing, sales, etc) and have them convince the developer to use it.
Developers do hate paying for things, but that doesn't mean you cant make a business selling to them. You just need to make a much more compelling offering than they could reasonably create themselves.
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.
cool, what versions of ghc? (or is it haskell platform only?)
(I am doing some 7.6.* heavy work, and thats ignoring occasionally playing with just patching GHC itself! :) )
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 :)
As a developer (who has worked with many other developers) I agree with your disagreement. Developers are just about the worst market I can think of when it comes to not wanting to pay for software even when the value is there.
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.
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.
Channeling patio11 here: $10-100 is really cheap, unless you're talking about per developer, per month, and then it's just cheap. Well, $10/dev/mo is cheap, $100/dev/mo is reasonable.
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.
Generally agree. What we are learning about our own product is that customers will either pay us really nice amount OR not pay us at all. We started out thinking we'd charge $29/mo. Now we are up to $99/mo and so far, we haven't had a single rejection as a result of pricing. Plenty of guys just don't get the need for our tool - but it isn't the price. Guys who get it just gloss over the $99/mo price.
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.
Or (d) they try to build it themselves, realize how horribly painful/complicated/problemsome/etc it is, and decide to find another approach.
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.)
There are two types of developers: those who make money writing code, and those who are tinkering around (think: college students toying around with Bash scripting)
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.)
After three decades of trying to code myself out of impossible situations I'm starting to depend on other people.
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.
Telling a developer to use something sounds like a bad strategy, we hate being told what to use. My cofounder and I are developers, and we've talked to a handful of other developers, and we've found that SaaS is appropriate for a lot of things. Others you definitely want to build yourself. But a lot of it depends on what stage your company is currently at. There's a reason all the big companies like SaaS, it's less resources they have to devote to something that is not core to their business.
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?
When there is no free alternative to what you are doing, they'll still buy (in my case that was hosting).
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.
Having spent a long time targeting the market for developer tools, I think you're underestimating that market based on your own experiences and social circle. It was a multi-billion dollar market in ~2006, only including IDEs, SCC, static analysis tools, architecture, and process-related infrastructure, and seems to only have grown since then.
> Your best bet at getting a developer product to succeed is to sell the tool to someone in another role
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.
I think this is changing slowly but surely. First, there are more pure technology companies nowadays, who have developer mindset in their DNA. Second, companies from all sectors understand importance of technology more and more, because they have to.
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.
I don't know if we hate paying for things, but it's certainly going to be hard for a single company to outperform any given popular GPL tool. I think you are right about selling to the company instead, but services (I don't want the hassle of running a Git server) are probably a better bet than a local tool (Not an improvement over vim/I could write my own that does it (IMO) better) if you are going for developers.
Demonstrably wrong. Developers (like anyone) are happy to pay for things if they can identify value. The problem is with the seller, not the buyer: people keep trying to sell things to developers that they can more easily build themselves. But today's platform as a service companies (like Twilio and others named in the piece) are providing a stack that can't easily be replicated by nerds working in isolation.
The giant asterisk with B2D is that you probably need a service component. There is a reason that github, mixpanel, etc, are all hosted services and not standalone apps.
Selling developer apps that are not coupled with some proprietary, hard to replicate service is risky because you are serving your entire dish to chefs who may just decide they don't like paying for it and would like to just make it themselves (and even give it away for free.)
There are plenty of opportunities for innovation in standalone tooling (like editors and code factoring tools) but outside of the Microsoft ecosystem it seems to be an uphill battle to get adoption of commercial software on developers' desktops. Maybe this will change.
I think there's a simpler reason for this. The criticism that developers might just copy your software doesn't change for SaaS. Github doesn't need to be SaaS, it's just sold that way, and plenty of Github-clones have arisen.
I think there's a much simpler reason standalone software is a rare beast outside business and enterprise: piracy. It's an odd world where Oracle database can be freely downloaded but IntelliJ requires a license and a videogame requires Steam or an App Store or something. The broad pattern in standalone software is the more consumer-oriented the software, the more barriers to piracy there are in place.
The difference is that Oracle's customers are easier to sue. Oracle makes its money selling five-figure server licenses and piracy is no threat, even if the pirate gets some utility off the software. Heck, the pirate might eventually be forced to buy a license if he locks himself in. On the other side of the market, the piracy rates on consumer software are astronomical--as in 90% being a typical piracy rate that I've heard--and pirates go overwhelmingly unpunished. SaaS fixes the problem by ensuring the consumer never has a physical copy to steal.
I'm not following your point. By your own admission, installed software in the enterprise is not as affected by piracy, so it seems to back up my point that there must be some other factor that prevents a commercial, installed application ecosystem to flourish in the developer tools sector.
I still think the service-oriented nature of github has a large effect. It's one thing for a open source clone of github to exist, it's another thing if it's something that IT needs to install and manage in your organization. On the other hand, your text editor, debugger, etc, are all things that IT doesn't care about beyond if it is installed and runs. So, the value of B2D is beyond the functionality of the tools per se but it's also the additional benefit of not having to run the service yourself to get its benefits. If that additional benefit were missing, the github-clones would thrive because they would be very close to equivalent in terms of time/cost/reward tradeoff for all members of an organization.
Totally disagree. The reason GitHub is a SaaS is because that's the most effective way to solve the problem. The problem with hosting git yourself is the hosting git. Then you have to worry about getting a machine from IT, and security patches on the server, and backups and ...
Software is eating the world = the cost of launching is coming down. Therefore more and more developers are starting companies. That translates into a lot more developers as decision makers. Developers who are serious about building businesses understand the criticality of focusing in on competitive advantage and not building every requirement they have for running the business. Therefore the real emergence of a B2D market. (I think the ones that are still in the "I can build this myself" mindset aren't going to scale much beyond their own project.)
My feeling is Stripe is the poster child for the B2D movement btw but not mentioned anywhere.
Calling B2D a subset of SaaS doesn't make a huge amount of sense.
Sure, there are some great SaaS products where developers are the main choosers/users, like Twilio, GitHub, HipChat and Parse. But the amount of time developers spend working with SaaS products is still small compared to the amount of time we spend working with local apps (e.g. vim, Visual Studio, git), programming languages/frameworks, databases, software systems (e.g. SugarCRM, Unreal Engine, Hybris) and of course PaaS/servers (e.g. Linode, AWS, Heroku). These are just as valid sectors of the B2D market as SaaS offerings.
Is it just me, or does the B2D market seem overstated here? How many developers are their that you can sell software to? I'll take the enterprise market over the developer market any day.
Don't forget about B2M (Marketers).
Companies like Wufoo, Mailchimp, SquareSpace, etc. Make it so you don't need a Developer to send your email, put up a response form, throw up a website.
That though could still be B2D. "Hey Mr Developer we need to do an online questionare. How long would it take you to build something like that?" "Go checkout Wufoo" (out of my hair so I can work on more important stuff)
This sounds really appealing - build a great service with an awesome API that developers love, and you're practically guaranteed success.
And there are a few good examples - Stripe and Heroku are killing it, right?
But the reality might be a little different. There are tonnes of businesses out there using crappy software products. Those businesses are not engineering-driven, and they'll continue using those products until a sales guy from BigCorp sells them the next iteration of those products. Even if there's a better product out there that "only takes 2 hours to integrate", their understaffed tech department already has a 12-month backlog.
As a SaaS company, focussing on nimble, fast-moving startups means that your sales cycle is fast, but you end up servicing companies with minimal revenues. It's like the ultra-vocal tip of the iceberg. 95% of traditional businesses still work on traditional sales cycles. It sounds crazy, but they freak out if they don't need to sign an NDA to get your API documentation.
We're in an interesting situation at Crocodoc (YC W10) where we're selling both to B2D customers (individual developers / small teams) and B2D customers (big organizations like linkedin and dropbox).
In our experience the trick to B2E sales is to make sure that (1) you're solving such a difficult problem that you can get over the initial "we'll just build this in-house" hurdle, and (2) you embrace the additional security/privacy/compliance requirements that come with most B2E solutions.
#1 came as the result of years of work (what we do -- displaying Office and PDF documents as viewable/annotatable HTML -- turns out to be super difficult), and #2 came from lots of customer development and lots of actual development (most B2D services don't have to worry about these types of requirements).
I think "B2D" is risky. Here are some potential problems:
1) Success of "the cloud" / SaaS. Many people are moving important data into the cloud but there are also more high profile outages, more high profile security breaches and more lock-in/proprietary/longevity issues.
For example, I like Asana but when Asana is down, I'm screwed, especially since they don't let me export my data. And it is down pretty often in my experience. Are you reading this, Justin the server guy?
Obsolescence through acquisition is also a real problem. I rely on XYZ service, they get bought and the buyer shuts it down. Now I have to extract my data and somehow move it to another service provider. That happens a lot. I'm sure we'll work through these issues, but I'd still peg a question mark on the whole SaaS model.
2) The sales model. Enterprise sales are appealing because they're big dollar. But they're hard. You have to get buy in at all sorts of levels in the organization and anyone can veto. They take a long time.
B2D circumvents this by targeting single individuals and small teams. That's good. It's the dropbox model. Get people using it, become viral, pervade the organization and become a standard. The trouble is that it uses a backdoor and backdoors can be closed. Many bigger organizations are fighting this tool fragmentation and the SaaS model in general. If bigger organizations successfully push ad hoc tools out of the company, then B2D basically becomes startup to startup. Then B2D is successful when startups have money. We've all seen how that pendulum can swing.
3) Myopia. Developers start startups. Developers know what developers need. So developers start startups for developers. Meanwhile there are tons of industries in need of powerful, easy to use, domain specific tools getting no love. Yes, computing is growing. IT is growing. Digital is growing. But there are lots of growth industries out there. It's the same reason B2C was big. We're all consumers. Most of us are developers. There are a tons of software project management tools out there. How many waste management tools are there? We're creating more trash than we are software (lots of trashy software but not enough trash software?)
Enterprise software is software purchased by people who will never directly use it in a sales cycle longer than most startup lifetimes. So it isn't always a great fit for startups.
In a gold rush it's good to be the guy who sells the picks. The great business model of Wall Street is to take a slice out of every transaction and let your customers take the risk.
Watch out Hacker Newser, these products are aimed at you, so they represent a smaller slice of the economic pie than is represented in your Bayesian prior.
There's a unique benefit, however, that one gets from being the center of a developer ecosystem -- other people work to make your platform great. This is as old as the IBM/360 and Apple ][, IBM couldn't capture the value of the PC platform but Microsoft could. It's as new as Facebook and as demented as Salesforce.com.
One of the teams in our incubator batch had a product for developers. I remember how Mårten Mickos (Founder of MySQL) gave them hard time:
"There are people who will spend any amount of money to save time, and there are people who will spend any amount of time to save any amount of money, and those are developers."
I saw where he was coming from. There is a reason why most developer tools are free, and even Apple charges only 99 bucks for their developer program. Developers are not a huge market and their willingness to pay is really low.
Later this team pivoted towards a much more lucrative space.
I'm super happy I had an internship with a VC. I got to see first-hand the Dunning-Kruger effect on a daily basis. I only wish I had the ability to short VCs that follow silly trends like this one.
Enterprise is lucrative in part because, at least historically, most developers have been out of touch with big business (with the possible exception of big software companies). So, the best ideas hadn't been picked over.
However, developers tend to hang out with other developers and be comfortable around other developers. So B2D is a very crowded niche.
Everyone who wanted to avoid learning about the problems of a new market has settled on B2D. Why start competing with this huge group?
I won't pay you for taking away stuff I love. No vim replacements, please.
But I will pay you for taking away stuff I hate, or can't. Here's a few ideas off the top of my head:
* cheap REST API based domain registration and DNS setup
* cheap rsync based backups (rsync.net minus support + cheap)
* pre-loaded legal cross-platform lightweight browser testing OS images, or hackable VNC based SaaS
* Strongly customizable imageless web site skeletons
* Mechanical Turk like service for design
* cheap REST based server encrypted file storage (Do a better job explaining the trust involved than S3)
* cheap raspberry pi co-location (low power, low cost, but dedicated). Optional 1TB USB drive and spindown code (I have this at home but it took me a day and I have 100Mbit broadband)
* cheap generic WLAN robot with REST interface (rolling hand with eye)
* Household chore automation devices
* Super fast shipping cheap 3D printing service with stress and durability certs
* Outsourced System Administration: Provide well tuned Debian based software stacks as simple pastable command line scripts in emails. Do the same for security upgrades. Be funny and edgy while doing so.
* Create designer raspberry pi case. Allow me to provide ROM and brand stamp. Ship to customers for me. Be cheap.
B2D sometimes works for infrastructure providers like Atlassian or Github. However, even those providers mostly cater for other businesses, not for independent software developers. The majority of developers - whether freelance or employee - has no incentive to pay for those services. They would have to convince their client or employer to use these services, which can be difficult especially if there are firmly entrenched incumbents.
Another problem for using services like Github is that most clients consider their source code a valuable asset and don't want it anywhere else but on their own servers.
Functional services like Twilio suffer from similar problems. It's hard to convince enterprise clients to outsource such functions to external providers even if their service is better than what can be produced in-house.
So, while there certainly is some value in B2D products, I disagree with the notion that it's larger than B2E.
This holds true for my API at https://openexchangerates.org, which is to its core a B2D service - I built it to service my own needs - whereas most of the key players in the industry seem to be aimed at business people.
The truth about many APIs is that it's the developers who are generally the ones searching for the solution they need, who then ask for finance dept or bosses to make the payment (this is true for at least 1/3rd of my customer base, in my experience - developer signs up, finance does the payment).
It's also developers who spread the word more about services they use, link back to things, write tutorials etc (where most of my traffic comes from).
Having said that, take with a pinch of salt - this is only from my personal experience with my business and may not hold up for everybody/anybody else!
Selling to enterprise developers is a grass roots strategy into the enterprise. Applications and services use a freemium model to get their initial users with the hope of becoming business critical. Once the tools show their worth, they are deployed at scale which triggers the paid version.
This approach has worked really well in the DevOps space since there is a strong motivation to use the same tools in development and production. Rather than being dictated from above about what tools to use, the developers are going to their management and saying "we need this to do our job". The enterprise ends up paying to keep their developers happy and productive.
What does this even mean? Do we need to find a new buzzword to obsess over?
Application development tools are nice. However, they're hardly a disruptive or new paradigm in the start-up world. How are people supposed to react to this? "Oh man, I see you're building an enterprise product...but does it fit the B2D model that the industry is dying for?"
Also, aren't the majority of enterprise products in some way or another automating some piece that used to be the burden on a team of developers within a company? I just don't like this type of fishing for new buzzwords and defining new industries that really just belong within the scope of an existing one.
The OP appears to equate "software for enterprises" to"software for developers in enterprises". In that case, B2D is a great strategy for getting a niche and building that out.
But I believe the real big money is in B2B solutions that aren't aimed at developers. It's a much bigger market, and it's easy to forget that most companies, large and small, aren't doing engineering all day. This does not mean that a successful B2B, non-B2D product can't be highly technological. I think Meraki has been an excellent example, for instance.
I find it strange that its some kind of epiphany that businesses should have some kind of actual revenue model when starting up. Certainly that was the tone i got from the article.
The sentence where I stated: "It seems like people are starting to wake up to the idea that startups should more closely resemble traditional businesses and actually make money by charging for a service they provide (radical concept)." was meant to be sarcastic. Guess that didn't come across...
Great post, another classic example is Atlassian! Perfect example of a B2D startup that has grown into a fully-fledged enterprise company with a very small/non-existent salesforce.
Mmm. As others have said, developers solve their own problems. What I like is Developer To Designer.
Designers work with the same tools as us sometimes, and every day we make them trawl through the command line or install gems. It's fun to be able to solve problems that other developers have created for designers.
Being able to program is not that uncommon a skill anymore. Just as you might expect customers to have a certain degree of literacy and numeracy, you can expect a growing number of them to be able to program.
Still think B2E is way bigger market but B2D is definitely a nice niche market with lots of room and more importantly helping developers build faster and better.
We recently launched www.SignUpasaService.com to help Developers build their registration, sign up and even payment pages in less than 2 minutes. One TC article later we already have hundreds of beta users!
Depending on how good the implementation is, this could be a good service, but seeing that even your own signup form was outsourced, I am so far unimpressed.
