Building an enterprise sales funnel is also a challenge. It takes real discipline to be able to say "100 leads->25 opportunities->5 POCs->3 deals at an ASP of 450k". With consumer apps, the volume is so much greater that you can have conversations about A/B testing the homepage to drive a few extra percentage points - for enterprise apps, odds are not enough people will ever visit your website to be able to gather enough data to A/B test anything.
And deals will fall apart for the most random reasons - a regime change at a big bank. A bigger company releases a product that uses some of the same words as yours, so the customer decides to evaluate it. Your EU channel partner gets bribed to tank a deal by a competitor. Anything can happen.
True story: we lost a deal once because the customer did a POC, and then fired the engineers who evaluated our software. With the departure of the engineers who evaluated the software, management lost the use case doc and evaluation criteria that was used by the fired engineers, so they wrote a new use case doc without telling us, scored us based on the new doc (despite never having used our software), then had a competitor come in and execute their POC with the new engineers and new use case doc. Unsurprisingly, the competitor "won". The call with the customer was amazing:
Them: You lost because of X, Y, and Z reasons
Us: Those weren't use cases in the pilot, but even if they were, we can do those things
Them: Well...we didn't know that you could do them. But it doesn't matter. We picked the other guys.
Us: Where are the people who looked at our software?
Them: We had to let them go. Unfortunately they didn't have time to write a report before they left, so we based our evaluation of your software on your user manual.
This is one of the reasons why SaaS apps are so appealing on paper. They have:
- Recurring revenue stream
- Freemium models allow leads to self-select
- Less sales friction (no need to send a sales engineer onsite, just spin them up a free 2-week trial)
But there's still a ton of money to be made in on-premise enterprise software, it's just a long, annoying, dangerous sales process.
Many companies will renew support contracts for years, even if they're not heavily using your software anymore, because the risk associated with their being out of support and then running into a critical issue is greater than the $100k it's going to cost them to renew. But if you've got 100 customers paying $100k/year to renew support, that's $10m in basically guaranteed revenue, which means that now you've got some breathing room to plan and grow sensibly. That's when the lumpiness goes away.
Selling to businesses (and governments, too) involves a lot of dealing with bullshit. Many times we've told someone we couldn't do the "absolutely must have" feature, and they still bought it. (Once the critical feature was to disable the copy protection, after which they would buy one. And when we refused they bought three.)
I think you've hit the nail on the head with the appeals of SaaS. Something else I would add to that from my "inside" perspective.
* People tend to be less territorial about SaaS as regimes and responsibilities change. It makes sense, premise stuff is a tangible reminder of someone else's influence and there can always be question about the quality of the implementation. Not so much with SaaS, it's regarded much more like a utility - no need to fire the existing ISP or power company when you take charge and no need to drop the SaaS contract.
* Less implementation friction. SaaS tends to be smartly designed with working around and through traditional barriers in mind. When all you need is a web browser and an innocuous configuration change or perhaps a lightweight agent or appliance to get started it's faster to get to the point of convincing adoption through demonstration as opposed to talking about it.
* No complications from folks who "buy" a product, but won't pay for ongoing maintenance creating mine-laden islands of trapped expense.
>"But there's still a ton of money to be made in on-premise enterprise software, it's just a long, annoying, dangerous sales process."
Yeah, I see it being particularly tough on an individual vendor. If you're addressing something apparent enough for one of the big monstrosities to notice they'll be looking to acquire/claim a solution to push you out.
If you're addressing something emerging, forward-thinking enough that the cartels haven't caught on to it, you'll have a steep uphill battle convince anyone what it is and how why they'd actually want it.
When we were smaller, we dealt with smaller companies. Most of the work was brochure sites. Although these bring in around 4-5x less than larger companies I found that it was easier to secure the deal and equally please the client. You can't build the same brochure site for a corporate and charge 4-5x more, it just doesn't work.
Now we are larger we deal with larger companies. The apps we build are larger and bring in greater deals. The chance of securing the deal though is a lot more than 4-5x harder. I also find the client harder to deal with. You end up dealing with people who are further removed from the people really making the decisions. You end up developing to the people you are talking to then you end up reworking projects when they actually show it to the people making the decisions.
All this process ends up costing us more but we are slowly refining processes for this. I suppose it's a learning curve in dealing with larger companies but I find each client has their own set of challenges.
We now service both types of clients. The quick and easy brochure sites for quick turnover and high profit and the higher end client who pays more but the profit is always less than if we did (x) amount of smaller sites.
You could call it "politics" or you could call it "people." Ultimately the world (even the technology world) is about people, more than about technology or economics. That truth often seems lost on HN.
In the world-facing project there might be millions of potential decision makers (i.e. customers). You can make the technical decisions you believe make the best product knowing that if you are correct you will gain more new users than you lose of old users.
In enterprise, sometimes you have to make whacky irrational choices because there might only be hundreds of potential organizations to sell to and they might have only 1-2 decision maker(s) each.
No one wants to lose customers. But at the end of the day if you know feature x is best for your application, you might make it even if it costs you 100 customers.
In enterprise its harder to make these choices because its harder / takes longer to recover.
However, it so often happened that a sale was made before a feature could be actually added as programmers were swamped.
It was common to add a feature years after it actually appeared in the product manual. Call it vaporware or deception but it was not uncommon. Internally, company hated the practice but every other company was doing it. It also shows how quirky client demands could be if some feature could go missing for 2 years and no one would notice.
I guess you could call it feature-on-demand-programming...
0. A monthly profit makes a business that can be sold (growth helps but is not required). 1. Same issues getting clients. 2. After some years, you have a steady income. 3. Some initial problems with cashflow (so we did consultancy also to earn money. Now we don't). 4. Provide a useful service with some customisation. Clients can't be bothered to change unless you are causing pain.
In the consumer space, you're working with averages over large quantities. The number of potential buyers is huge, so you need to build a product that, on-average, will result in more sales than non-sales when the customer reaches the point of making a decision. This decision point might happen tens of thousands of times -- sometimes millions -- a year for consumer products.
In the enterprise world, the number of sales opportunities are smaller by orders of magnitude. Every sale becomes a huge gamble, and as a result you tend to throw an immense amount of resources at every sale. This is also one of the primary reasons enterprise software ends up so bloated and unmanageable. On the front-end, the decision making process for purchasing enterprise software is driven by checklists and "due diligence" procedures that are horrible at accounting for software quality. You're more likely to win an enterprise contract by saying "sure, we'll add that feature" than you are carefully explaining how maintaining product focus results in a more usable product.
This makes enterprise software a high-stakes game. A sale results in windfall revenue, but a non-sale can severely strain cash-flows. At the end of the day, you're still trying to beat the averages, but you're working with a much smaller number of opportunities, so wins and losses move the needle in a big way. I think this is a significant incentive for small shops and independent devs to avoid the enterprise space. You need a larger bank roll to attack the enterprise market. We bootstrapped our company, and we hit several gut checks along the way. The days of writing large checks to my company are not quickly forgotten.