Enterprise is sexy now. But B2D is sexier.
blog.yonas.io
blog.yonas.io
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.
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 :)
Also, frictionless CI as a service? You are doing God's work. I hope you succeed.
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?
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.
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.)
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.
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.
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.
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.
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. :) )
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.)
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 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 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.
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.
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.
Case in point: at SnowPlow (https://github.com/snowplow/snowplow) we are squarely in the B2D market, but are not a SaaS business.
1. Pour dumb VC money into companies with no business plan.
2. Discover that revenue does actually matter.
3. Pivot to the golden fields of B2B where money flows like water.
4. Discover B2B is hard and slow. Run out of money. Crash hard.
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.
And maybe we have to adapt to that.
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).
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?)
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.
"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.
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.
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.
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!
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.
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.
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.
http://techcrunch.com/2012/01/16/atlassian-2011-revenues-102...
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.
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!