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.
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.<p>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.)<p>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 it flows like this:<p>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.)<p>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.<p>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.<p>Case in point: at SnowPlow (<a href="https://github.com/snowplow/snowplow" rel="nofollow">https://github.com/snowplow/snowplow</a>) we are squarely in the B2D market, but are not a SaaS business.
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.
Now my 1999 deja vu is complete.<p>1. Pour dumb VC money into companies with no business plan.<p>2. Discover that revenue does actually matter.<p>3. Pivot to the golden fields of B2B where money flows like water.<p>4. Discover B2B is hard and slow. Run out of money. Crash hard.
This sounds really appealing - build a great service with an awesome API that developers love, and you're practically guaranteed success.<p>And there are a few good examples - Stripe and Heroku are killing it, right?<p>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.<p>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.<p>And maybe we have to adapt to that.
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).<p>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.<p>#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:<p>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.<p>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?<p>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.<p>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.<p>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.<p>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.<p>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.<p>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:<p>"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."<p>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.<p>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.<p>However, developers tend to hang out with other developers and be comfortable around other developers. So B2D is a very crowded niche.<p>Everyone who wanted to avoid learning about the problems of a new market has settled on B2D. Why start competing with this huge group?
Oh please, market to me.<p>I won't pay you for taking away stuff I love. No vim replacements, please.<p>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:<p>* cheap REST API based domain registration and DNS setup<p>* cheap rsync based backups (rsync.net minus support + cheap)<p>* pre-loaded legal cross-platform lightweight browser testing OS images, or hackable VNC based SaaS<p>* Strongly customizable imageless web site skeletons<p>* Mechanical Turk like service for design<p>* cheap REST based server encrypted file storage (Do a better job explaining the trust involved than S3)<p>* 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)<p>* cheap generic WLAN robot with REST interface (rolling hand with eye)<p>* Household chore automation devices<p>* Super fast shipping cheap 3D printing service with stress and durability certs<p>* 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.<p>* 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.<p>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.<p>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.<p>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 <a href="https://openexchangerates.org" rel="nofollow">https://openexchangerates.org</a>, 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.<p>The truth about many APIs is that it's the developers who are generally the ones <i>searching</i> 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).<p>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).<p>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.<p>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?<p>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?"<p>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.<p>But I believe the real big money is in B2B solutions that <i>aren't</i> aimed at developers. It's a much bigger market, and it's easy to forget that most companies, large and small, <i>aren't</i> 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.
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.<p><a href="http://techcrunch.com/2012/01/16/atlassian-2011-revenues-102-million/" rel="nofollow">http://techcrunch.com/2012/01/16/atlassian-2011-revenues-102...</a>
Mmm. As others have said, developers solve their own problems. What I like is Developer To Designer.<p>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.<p>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!