Ep. #15, All Software Is SaaS

Paul Biggar: What you're saying is that all software has become SaaS.

Edith Harbaugh: Hey, I love the SaaS service, but I want an on-premise version.

Paul: So it's SaaS by the new Wall Street definition of SaaS.

Edith: The first feature flag is easy, is when you start to have 50 and you want to control them and manage them, that's what is hard.

Paul: One of the main reasons that people want other people's software is that it's more secure than writing it themselves.

Edith: Well, everything could be written in fifty lines, I thought.

One of the last holdouts against continuous delivery is SDKs.

Paul: It's not like back in the old days when an SDK was an SDK.

Edith: This is pretty inside baseball.

Paul: Hi, I'm Paul Biggar, founder of CircleCI.

Edith: I'm Edith Harbaugh, CEO and co-founder at LaunchDarkly.

Paul: And you're listening to To Be Continuous, a podcast about continuous delivery and software development.

Edith: You can get in touch with us anytime at our Twitter handle, @continuouscast.

Paul: The show is brought to you by Heavybit. To learn more, visit heavybit.com. And while you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.

So we're going to talk today about SaaS, about software as a service, and about how that relates to continuous delivery.

SaaStr and What SaaS Means

Edith: So Jason Lemkin runs a huge conference called SaaStr. It was just called one of the top conferences that an entrepreneur can go to. And when I looked at who was attending, it's basically everybody who's making software.

Paul: Right.

Edith: You know, so his original premise was that you need a conference just for software as a service. And this was that conference, and now it's just, I look at it and like, "Well, this is just software."

Paul: So what you're saying is that all software has become SaaS.

Edith: Yeah, and even beyond that, SaaS in itself has then turned around and gone back to on-prem.

Paul: Right, right, right.

Edith: Which on-prem is on-premise, where a customer takes a version and they install it on their own hardware, which is, at that point, is it still even SaaS?

Paul: Right. So I guess a good place to start is to say we think of SaaS as being software as a service. Like, it's software that you run in the cloud or something like that. Is that really what SaaS is? Is that a modern definition?

Edith: Well, so the original definition was a movement away from how software was sold when I started off, which was people bought a three-year license and they got a version of it, and then they would pay 18% or 20%, depending on what they negotiated, for updates.

Paul: Okay.

Edith: And what would happen then is that people would get cheap or they would forget. And they would stop paying their support, and then they would just have this old perpetually good, and I'll put an asterisk by perpetually good, version they could run for forever.

Paul: Gotcha, gotcha.

Edith: So there's still a lot of customers out there who are running Vignette V6, which was the original product that came out over a decade ago.

Paul: That kind of gels with my understanding of what people are talking about when they talk about SaaS. It seems to be a lot more of a business model than it is necessarily about how software is delivered.

So the idea of recurring revenue based around having to pay every year, all the time. And how the software is actually delivered, whether it's sold on-prem, whether it's sold in the cloud, whether it's a per seat license or whatever, seems to be rather separate from how people think about SaaS.

Edith: I think they've gotten mingled in people's minds now, though, because you have the whole second wave of people saying, "Hey, I love the SaaS service, but I want an on-premise version."

Paul: Right, right, right. I remember talking to Coverity when they were transitioning from their on-prem licenses. I think they were selling it for something like eight cents a line of code or something like that. And then they were transitioning to a SaaS model.

And the reason that they were transitioning to a SaaS model was they were going public soon. And the economics of a SaaS model are well understood by Wall Street and are well understood by public companies, and are much better economics and much more predictable and just much more profitable all around than the old model of selling the enterprise software and the maintenance fees.

Edith: Well, so Paul, this is hilarious for two reasons. One is I remember when SaaS was something that Wall Street didn't understand.

Paul: Right, right.

Edith: Like when Salesforce was the new kid and they had their actual logo was software with a slash through it.

Paul: Right, right. Well, I mean, it was fifteen years ago. You assume that bankers and investors can learn something over fifteen years.

Edith: Well, because the very nice thing about the other model, the on-prem model, is you get all the money up front.

Paul: Right, right. So yeah, there's a different accounting model. And a lot of people have spent a lot of time talking about the accounting model and when you can recognize revenue and...

Edith: Yeah, it's a headache. I don't want to talk about it at all.

Paul: Yeah, yeah. Well, you'll go public one day and you'll have to deal with that shit.

Edith: I had to do it at TripIt because TripIt was a division of Concur, and part of what I did was a lot of revenue reconciliation, and it makes your head spin.

Paul: Right.

Edith: So the second funny part is, so one of our advisors is Andy Chou, who was the co-founder of Coverity.

Paul: Right, right, I know Andy.

Edith: I think what surprised me is originally I thought there's no reason why anybody should want on-prem, but actually we're having customers who are requesting it for various reasons.

Why Customers Want On-Prem

Paul: Right. So I mean, the main reason, I'm guessing, is security policy.

Edith: Yes.

Paul: They get to, not necessarily that it's more secure, but that they get to deal with how secure it is, or they get to... I mean, one of the main reasons that people want other people's software is that it's more secure than writing it themselves.

A reason to buy software versus building it yourself is that you can trust that these people have a dedicated security team and spend a lot of time thinking about the edge cases and that kind of thing. And one of the nice things about SaaS originally is that you didn't have to install it on your machine and worry about updates and worry about security and worry about firewalls and that sort of thing.

But as you say, some people, especially large enterprises, are very into worrying about that sort of thing. And they have four hundred item checklists that you need to fill out before you sell software to them, and it's all about security.

And it's not, I mean, I'm actually gonna say it's not really about security, but it's about the security process, which is, I think, for many large companies more important than the actual security of the situation.

Edith: You're basically calling security theater?

Paul: Not exactly. When you get to a certain size, you can't actually guarantee security, and so what you do instead is you establish processes, and then there's someone to... There's a scapegoat somewhere. You have plausible deniability because you spent the time and you did the ISO process or the HIPAA or whatever it is.

Edith: So I actually have a tangent. So I wrote an article on staging servers, which was deliberately provocative. And my mom writes ISO standards.

Paul: Oh, really?

Edith: Yeah. And I always kinda make fun of her 'cause I'm like, "Oh, mom, nobody actually follows those in the real world," basically, which is kind of a jerk thing to say.

Paul: Right, right.

Edith: But what she said back to me is that the standards always lag by ten to fifteen years of reality of the world.

Paul: Right, right. Of course they would.

Edith: Which was a polite way for her to put that. So back to your point.

Paul: So what I'm saying is that it's funny that people look at going on-prem with a SaaS product to deal with security when one of the initial great parts about SaaS is that you don't have to do that. Someone else is running the software.

Edith: I didn't think that was the reason why people bought... So actually I have two more interesting data points. From my perspective, it wasn't security that people bought SaaS. It was that they didn't want to take on the cost of hardware.

Paul: Okay. As in a CapEx sort of arrangement?

Edith: Both the CapEx and the people. Like, I remember when you used to, like... So I was an engineering program manager and a product manager of an installed product. And when I went to customers, they had to maintain a staff of people

Paul: Right, right.

Edith: who did the care and feeding of an entire stack.

Paul: Yeah.

Edith: Like, you know, they had people who would, you know, database, web server.

Paul: And this is the thing now, when, as a small company, when you buy SaaS, you're not just getting the software, but you're getting a team of five people who keep it operational and people who are building the new stuff and all that sort of thing. And you're paying, like, fifty or five hundred or five thousand dollars a month for this, which is infinitely cheaper than you could do otherwise.

Edith: You're basically buying the economy of scale that you don't have to spin up your own app server to run every piece of software that you've bought.

Paul: Right. So when we talk about what SaaS is, right? A lot of us think of SaaS, a lot of us engineers especially think of SaaS as being in the cloud.

Right. SaaS is a thing that is run by the vendor on the public cloud, it's a multi-tenant thing. It's, you know, thing that updates all the time.

It's quite synonymous with continuous delivery or something along those lines, and it has APIs and they're RESTful and all that sort of thing. So the modern SaaS tool that us developers are used to.

And when you look at installing that on-premise, you actually get the vast majority of the benefits of it. You just don't get all of them. So I mean, you get the modern tool, you get the REST APIs, you get the cloudy bit.

I mean, it runs... Very often when people are talking about installing on-prem, what they're talking about is installing it on AWS virtual private servers. Or VPC, virtual private cloud. Or you're running it on VMware, and you're not actually being given something which, you know, can install on sixteen different flavors of Unix like it was ten years ago when people were selling software.

So you're getting VMs probably, or you're getting container images. And that's a very different world than it used to be. And so you're getting still a lot of the advances.

So if you buy Circle on-prem, you know, it's part of your cloud and it scales up and it scales down, and you're not, like, managing a particular set of servers in the way that you are. In fact, a lot of the server management, or a lot of the scaling, is built into the product itself.

So you're, you know, dealing with a control panel, which is probably a fairly part-time job for one developer, rather than, you know, an entire team is managing the database and managing the stack and all that sort of thing.

Salesforce as the Original SaaS

Edith: Yeah, and exactly what you said was one of the big original draws of Salesforce.

Paul: Okay, go on.

Edith: So one of their original draws, when their literal logo was no software, is that, like, "Hey, you don't have to buy this entire stack of people to run..." If you're a sales organization, which Salesforce originally was, it's like you want to get visibility into your pipeline. You don't want to have to employ an entire IT staff to get that.

Paul: Right, right, right.

Edith: Because that was the way...

Paul: That's what you did with Siebel or something, right?

Edith: Yeah. I mean, that was SAP's whole business model, is that you bought these incredibly complex packages to run your business processes, and then you own them, you know, top to bottom vertical implementations.

Paul: Right, right. It's funny that Salesforce is the original SaaS, because I don't think any of us who look at modern SaaS would look at Salesforce as a pinnacle of it. So they do quarterly releases and they're not continuously delivering.

Edith: And I think it's, they get pulled very much by their enterprise customers. And they did this before they had an effective feature flagging management system.

Paul: Right, right, right, yeah.

Edith: And by the way, thanks for wearing your LaunchDarkly shirt today.

But so Salesforce got pulled so far with all these one-offs for different customers that I heard at one point it took them two years to make any release.

Paul: Wow. So the fact that they got it to quarterly cycles is probably a very positive thing for them.

Edith: Yeah, what happened is they got to this point where it was a two-year cycle and they're like, "We can't do this anymore." And then the two-year cycle just to, like, change anything.

Paul: Yeah, yeah, yeah, yeah.

Edith: And that's when they hired a lot of agile consultants. They're like, "We need, you know, to just quarterly, we need to be faster."

Paul: Right, right, right, right.

Edith: So which is a sea change.

Paul: Quarterly is not fast enough for those of us on kind of the small side of things, or also the big side of things. Facebook would have a revolution if they said, "Quarterly is how often we'll release."

Edith: Well, I think, so Salesforce is interesting. I actually, they are very much the incumbent. So they're not really selling on innovation.

Paul: Right, right, right, right. It's funny because the amount of Salesforce replacements that are out there. I read somewhere that there was 1600 sales and marketing automation companies that were funded last year.

Edith: Yep.

Paul: And, like, those are sixteen hundred Salesforce competitors.

Edith: Well, I think it's kind of, Salesforce is the way IBM used to be.

Paul: Right, right, right. It's an ecosystem and consultants and partners, and you'll never get fired for buying Salesforce.

Edith: Yeah, exactly. If you're gonna run your sales pipeline, it's like, do I wanna go with this new risky tool or not?

Paul: Right.

Edith: So I said something to the team the other day, which they didn't say was much of a pep talk. But I said the only reason people bought LaunchDarkly is because they were truly desperate.

Paul: Okay.

Edith: That there is really no alternative to us in the market. You know, if IBM was making this, if Salesforce was making it, if this was something that was not...

Paul: Right. This is enterprises that are buying.

Edith: Yeah, we have a lot of enterprise customers who are...

Paul: They're buying from a small startup because they're desperate. That's the crux of it.

Edith: But desperate in a good way. They're like, "We really need this."

Paul: Right, right, right.

Edith: So they're trusting us. That was the end of the pep talk.

Paul: It sounds like IBM should buy you.

Edith: I hear that LaunchDarkly is very popular these days.

Paul: I see.

Edith: So we originally had this thesis that we would be a lot of small companies, instead we have big enterprises. We're like, "We need this."

Paul: I mean, it's one of those things where small companies, they think they can build it themselves. And in fact, there are libraries out there to do feature flags and that kind of thing. So you can do a fairly effective feature flagging mechanism with one or two developers, kind of, you know, just taking a library and off the side or something like that.

And it's really when you've done that for a couple of years that you start to see the error of your ways.

Edith: I mean, really what we're selling is feature flag management.

Paul: Right, right, right, yeah.

Edith: Like, so somebody did a, you know, a diss on Twitter, which was, you know, "I can implement a feature flag in fifty lines of code." And I'm like, "Yeah, of course you can."

Paul: Right, right, right.

Edith: Like, the first feature flag is easy. It's when you start to have fifty and you want to control them and manage them and see who touched them last and how, like, that's what it's hard.

Does SaaS Need Salespeople?

Paul: So going back to SaaS and that sort of thing, you were talking about SaaStr originally and you were talking about Salesforce as, you know, kind of a model that ended up having lots of salespeople and that sort of thing.

One of the original things that I felt about SaaS and that people were talking about SaaS was that it kind of sold itself.

Edith: Yeah.

Paul: Didn't need salespeople that much, and you could buy SaaS with a credit card, and people talked all about Basecamp and the 37signals stuff were kind of early successes in the SaaS world, and they were like, "You know, there's no salespeople here, you just buy with a credit card."

Edith: Yeah. So I think you're right. There was a belief a while that SaaS was synonymous with self-serve.

Paul: Yep.

Edith: That if you didn't need to go get your IT department to go install this, if, the old SAP model, if you didn't need somebody to install it, if you didn't need people to configure it, if you could just onboard yourself, why do you need a salesperson?

Paul: Right, exactly. And there was a low price point associated with that. People were typically selling very low price things. Certainly not things that cost thousands of dollars or tens of thousands of dollars.

Edith: So I think there's two things that are happening there that are making salespeople be part of the ecosystem. It's more and more complicated things that are being served over SaaS.

Paul: Okay.

Edith: Like, again, I remember when everybody's like, "Oh, you can never, for example, have Portal Server or something that's actually technical be a service." Now AWS is a service.

Paul: Right, right, right.

Edith: Like, so now that there's more and more technical things, and I say not technical just in terms of dev tools, but more technical in terms of marketing automation, sales automation. When you have a bigger purchase, there is a need for a salesperson.

Paul: Right, right. Maybe more than a salesperson. I mean, salesperson definitely, definitely useful, but when you have the product, you need an account manager and you need someone who you can email and say, "Something is wrong, help us right now."

And related to that, when you're getting installed, you need a sales engineer and you need someone to manage the process and make sure... I mean, no one ever needs a salesperson. You can always carry yourself through the process. If you wanted to buy software, right, and you were desperate to buy software, you could get yourself through it.

Edith: So it's interesting. I mean, I'm sorry, Paul. I'm talking a lot about my own company today. What we saw with LaunchDarkly is that we originally thought we were gonna sell directly to developers.

Paul: Right.

Edith: What we saw is that we had a different buyer persona than a user persona.

Paul: Right, right, right, right.

Edith: And I think that's where you insert salespeople into any SaaS process.

Paul: What I'm saying is that you're inserting it because it is a more efficient way for the company to ensure that sales happen, not because it's necessarily required.

Edith: So here's my own experience. We originally thought we were going to be very much like Atlassian.

Paul: Okay, yeah.

Edith: Which is deep in our DNA. My co-founder John is from Atlassian and our first two engineers were Atlassians. For a while it was me and three Atlassian people.

Eventually I came to the realization that even though I would tell people, like, "Hey, you could just go start using our product," I was actually talking more to directors of engineering or CTO who just wanted more information from me right before they decided to invest for their entire organization.

Paul: Yeah.

Edith: Like, PVH put it the best. He's like, "They want to hear that there's a real person behind this."

Paul: Right, right, right. So looking back at Circle, the vast, vast majority of our customers bought without talking to any other human at all. Maybe they emailed support, but it wasn't a sales process, it was completely self-served. And this was true for the first three, three and a half years.

Occasionally people would request their CFO to have a conversation with someone on our side or...

Edith: The CFO?

Paul: Yeah, just to, you know, allow them to gain confidence that there's a real human there, and to sign off on the purchase. And I think that was one of our first thousand dollar customers, our thousand dollar a month customers, that they were like, "You know, our CFO wants to know that you're a real company," and at the time we were five people, you know, scarcely a real company at all.

So we were selling ten thousand dollar a month contracts without a salesperson.

Edith: But you had a salesperson.

Paul: We had a salesperson, absolutely. We had a part-time salesperson.

Edith: No, you were the salesperson.

Paul: I was the salesperson, yes. And that's what I mean. But it was part-time and I wasn't exactly running the process.

You know, I didn't have a big, like, checklist of where everyone was in the pipeline and following them through. I was largely answering emails as they came in, and the customer was driving the process because they desperately needed it. That's a very different sales process than people buying the on-prem.

So people who buy Circle on-prem are talking to a salesperson. They want to talk to a salesperson. They want someone who will manage the process for them and make sure that it doesn't drop off the radar because they've got, you know, a quarterly goal that's associated with getting CI in place.

And they have forty different steps that they need to go through to be able to buy software, and they need someone on the other end who's actually going to do that. And it's not going to be a support team. It's gonna be a person whose job it is to make sure that happens.

Edith: A good salesperson helps everybody look good.

Paul: Right. So we've gone from a place where people bought almost entirely self-serve to a place where people, and I mean as an industry, as the SaaS industry, to a place where people use enterprises. And you're right, it's a lot to do with the complexity. It's a lot to do with, like, people selling larger price points and larger companies looking to buy SaaS.

So at the start, you could buy your Salesforce SaaS, whatever, and, you know, those guys had tons of salespeople to deal with that. But the vast majority of SaaS looked a lot more like Fog Creek and 37signals, and there were no salespeople on the other end.

Now people are selling much, much higher price points. And, you know, I'm looking at a company like... Do you know Hearsay Social?

Edith: Yeah, it sounds familiar.

Paul: They're based in Mission Bay. They sell some sort of predictive model based on your social profiles to, like, insurance companies and that sort of thing. So there's something like...

There's something like 200 potential customers for them in the entire world. And they're massive, massive contracts. And so they have a massive sales team, right? Or maybe not a massive sales team, but it's entirely sales driven, right? Because you can't sell to one of those two hundred giant companies without having a sales team that is managing every step of the way.

And that is an entirely SaaS product. There's no on-prem. It's all in the cloud and it's all managed on the Hearsay's servers. But because of the business model, they need a sales team. And the price point.

Edith: Paul, this is pretty disappointing, but I agree with you again. I think what's really happened is that SaaS was originally scary and new, so it was very much low market.

Paul: Right.

Edith: And it's just moved up the food chain and is at higher and higher price points.

Paul: Right.

Edith: Like what you said. Like, some Hearsay, they're not just gonna tell one insurance agent, "Hey, install this and start giving quotes."

Paul: Right, right.

Edith: It's something that has to come organization-wide, and at that point you need a salesperson.

Joel on Software and Continuous Delivery

Paul: I remember the way that many of us in this industry learned about SaaS was reading the Joel on Software discussions about how they sold Fog Creek and why they switched to a web-based thing. I'm not sure he used the word SaaS. Maybe it was cloud, maybe there was a...

Edith: Maybe pre-SaaS.

Paul: It wasn't pre-Salesforce, but I think it was pre-the rest of the industry knowing about SaaS. And, you know, part of the benefits there was the vendor controls updates.

Edith: Yes.

Paul: The vendor decides exactly when the software gets updated, and they deal with security things, and they get the exceptions, so you don't need to do bug reports, or you don't need to do as many bug reports. You get a lot of that information yourself instead of having to collect logs or that sort of thing.

And it feels very different from how we look at SaaS today. In the sense that SaaS is kind of a business model, but at the same time it feels a lot the same in the sense that there's a very strong tie between what Joel was talking about and continuous delivery.

Edith: Yeah.

Paul: To me, modern SaaS has very, very strong parallels, or maybe very strong correlation with continuous delivery. And I think if you can't do continuous delivery on it, it would be very difficult to refer to it as a SaaS.

Edith: Yeah, so I'd say continuous delivery has really cheapened SaaS. And I mean that very good. It's brought down the cost.

Paul: Right.

Edith: Because I remember the old days where you would have all these versions at different customers, and then you would try to coax them to upgrade.

Paul: Right, right. And you would have to back port changes to the old release branch and be able to...

Edith: And a lot of times they couldn't upgrade because it meant having to upgrade all the underlying stack also.

Paul: Right.

Edith: So then you got into this very complicated dance if you're like, "Well, you're on Sybase version blah."

Paul: Yep, yep. The new version no longer supports Windows whatever. Or Unix whatever.

Edith: This huge cost in old software, which was just making sure that you could work on all these old versions, and you had migration scripts.

Paul: I would think that almost one of the definitions of what is and what isn't SaaS is whether or not there's a migration plan.

So can you continuously upgrade that software? And when I look at Circle's on-prem thing, it's, you know, we're not supporting 57 releases. We're largely supporting the latest release. And if you want, there's a button that you click to upgrade to the latest release.

SDKs as the Last Holdouts

Edith: That's funny. Oh, go ahead. I was thinking one of the last holdouts against continuous delivery is SDKs.

Paul: Okay.

Edith: I think we talked about this before, but, like, we have some customers right now and we're like, "Please, please, please move off that SDK."

Paul: Right, right, right. I'm impressed with, there's a bunch of people out there who do very interesting stuff around SDKs, and I think Stripe is kind of the major one. So Stripe versions their APIs.

Edith: Yeah.

Paul: And Stripe obviously is never gonna do on-prem because it's payments and cloud and that sort of thing. But every time that they do a breaking change, they just make a new version of their SDK, or of their API.

And you can use whatever version of the API you like by sending a header. Or by default you're using whatever version of the API you are stuck on. And they do a transformation from the old APIs to the new API, so they almost never need to deprecate old APIs.

Edith: Interesting. But those are APIs, not an SDK.

Paul: I mean, I don't know how exactly they do their SDKs, but I presume that their SDKs make calls to the APIs. And so if you're on the old version, maybe that API doesn't exist. And so you get an error. But you'll get a version error as opposed to, you know, something subtly failing or something like that.

Edith: Yeah. This is pretty inside baseball.

Paul: I think the major thing is that SDKs are largely small wrappers around APIs these days.

It's not like back in the old days when an SDK was an SDK and ten men were men.

Edith: What exactly was that day? Was it, like, a fixed day and time that you remember?

Paul: I mean, I'm thinking of, you know, when you downloaded the SDK to, I don't know, work on, you know, the hardware product or something like that. Some SDK came with Windows, or, I mean, actually, if you're looking at, like, SDKs that come with Apple or phones or, you know, whatever, you're still kind of trapped in that sort of model, versus SDKs that come with SaaS are kind of small wrappers around the API. Very, very often, like, literally tiny wrappers. And many of them you could almost define with a schema. And, you know, you could write the whole thing in 200 lines.

Edith: Well, everything could be written in fifty lines, I thought.

Software Without a Migration Plan

Paul: So when you're looking then at what isn't SaaS, if you haven't got a migration policy, or if there isn't a way to migrate, I'm gonna say that you couldn't really refer to it as SaaS. I find it hard to think of an example.

Edith: I think I know what you're getting at, because that's not really a service. If you're taking it as software as a service and you're just saying you're on this version for forever, I think I agree with you, but I'm hard-pressed to think of somebody that actually does that.

Paul: That has a migration plan?

Edith: No, that has no migration plan.

Paul: Right, right, right, right.

Edith: The closest I could come to is all that freeware or shareware that used to float around.

Paul: Well, yeah, I mean, this is exactly it. If you're selling, you know, like you were talking about, whatever software relied on, you know, version six of Sybase or whatever that was, you've got no migration plan because you've got no maintenance contract.

There's a bunch of, like, libraries and a bunch of kind of OSS software that ships without migration plans or without, you know, scripts to upgrade from one version to the other.

And I remember you talking about the company that did the upgrade from version six to version seven and had no migration plan at all. What was this again?

Edith: It was Vignette. So the reason why there's still a lot of V6 out in the world is because there was not really a migration path from V6 to V7. They should have just started as a new product line.

Paul: Gotcha.

Edith: Because they switched from Tcl. So V6 was Tcl.

Paul: Right, they rewrote it in Java.

Edith: They rewrote it in Java.

Paul: Everyone did.

Edith: I'm sorry?

Paul: Everyone rewrote it in Java. Whatever it was, it was rewritten in Java.

Edith: Dissecting it, it was a smart thing to do in that Java was the wave of the future. And that seems dated now, but at the time it was, this was 2001. But they should have just said, "Here's our Java version," and just called it V1 of Java instead of saying, "This is the next iteration," because what it basically did is it stalled everybody at V6.

And then what happened was competitors came and said, "Well, the amount of effort to go from V6 to the V7 is equivalent to you just moving to our platform."

Paul: Right, right, right, right.

Edith: So they got picked off by all the other competitors who were like, "If you're already going to all this effort." Because they stopped doing updates on V6 for a while.

Paul: Right, right.

Edith: Because they want everybody to move to V7.

Paul: So SaaS then overall has salespeople, unlike when it started, very closely tied to continuous delivery?

Edith: So I am arguing both sides of this now. I don't think all SaaS has salespeople.

Paul: Like, for example, if you're going to the SaaStr conference, you're gonna learn about salespeople.

Edith: Oh, I have to do that.

Paul: A lot more than you're gonna learn about SaaS.

Edith: Yeah, I mean, like, so for example, I'm thinking of the software we use, like, we use Quip. We use Pipedrive. These didn't have salespeople, but we're at a pretty low price point. So we can't economically support a salesperson on it. You know, if we're paying, I think if we pay, like, I don't know, thirty-nine dollars a month or something like that for...

Paul: At some point, Dropbox, which we pay a relatively low price point for, we will hit salespeople size at some point. There are salespeople who sell Dropbox to larger companies for much, much larger price points.

Bundling Hardware with On-Prem

Edith: So I had one more interesting point about on-prem. So the original thing about SaaS was that you didn't have to have the cost of buying hardware. So I have a friend right now who is selling very effectively on-prem, and he's bundling into his on-prem solution the cost of the hardware.

Paul: Okay.

Edith: And I said, "This seems odd to me," and I asked him why, and he said, "Well, otherwise the people who are buying on-prem would have to go and provision the hardware and order it, and that would create long delays."

Paul: Right.

Edith: And he wanted to get these contracts signed.

Paul: I mean, this is the thing. People sell, you know, servers that you rack rather than software that you install onto the servers.

Edith: But he, so he's going back, he's actually selling the whole stack. So he's selling people... Originally he started selling people software, and then he's like, it's taking them too long to get hardware and I want to close this deal.

Paul: Right, right.

Edith: And they're willing to pay for the hardware. So he sells it as a bundle.

Paul: What does that do to the margins?

Edith: That was kind of my question. He's like, right now, it doesn't matter to him.

Paul: Okay. It's early stage. It's...

Edith: He's selling the hardware for profit.

Paul: Yeah.

Edith: And mainly he just wants to get these customers on board instead of waiting 'til a year for the next budget cycle for them to get their own hardware.

Paul: So how is that related to...

Edith: So basically it's a SaaS company that's twisted back on, and now it's...

Paul: Why is that a SaaS company?

Edith: Well, he thinks of himself as a SaaS company, but now they're doing on-prem and selling hardware, and I'm like, "Well, this..."

Paul: Right, right. And they do recurring revenue, I presume.

Edith: Yeah.

Paul: Right, right, right. So it's SaaS by the new Wall Street definition of SaaS.

Edith: But it's, when you look at it, you're like, "Hey, this is a lot like the old days."

Paul: Does it have a migration plan?

Edith: I should ask him that.

Paul: Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Biggar of CircleCI, and Edith Harbaugh of LaunchDarkly.

Edith: To learn more about Heavybit, visit heavybit.com. While you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.