Kyle Cordes: My name's Kyle Cordes. I operate a little bitty company here in town called Oasis Digital. We mostly do consulting for medium sized companies.

What I want to cover first here is a real simple and encouraging idea that may have never occurred to you if you have always worked for a consulting firm, for your whole life. You can take your computer out when somebody is not paying you, and write some software, you can write some text, and you own it. It is yours. That's what copyright law says. You don't even have register it to own it. You can register, but you don't have to.

That's a really powerful idea, if you think about it. You don't have to do things that become somebody else's immediately on their creation. You can make that investment yourself and they become yours on their creation, and then you can decide whether you want to sell it. You can make something, and then decide not to sell it to anyone, ever. It is yours. You have the right to do that, even if somebody else desperately wants it. You could decide not to.

You could sell it to them by selling them the hours that you spent making it, which is what we do in consulting. It is what my company does most of the time. You could sell them the product when it is done. You could build something speculatively and you could sell it with all the rights.

I could spend a year writing a fantastic game, find somebody... it wouldn't be a very fantastic game in a year. I could write a decent casual game in a year, find somebody who wants to pay me X thousand dollars for all rights to it and make that lump sum payment at the end. Of course, you might come out better or worse than if you had spent that year working for somebody.

There are other things you can do, too. You might choose to not sell the software permanently to anybody. Just to rent access to it. Paul Graham did a talk and an essay on his web site a few years ago called "The Other Road Ahead." Is anybody familiar with that essay?

If you haven't read stuff on Paul Graham's web site, go to that web site and read all of the essays on it. That's my advice. It will take a long time, because they are great in number, but they are extremely well written. Even if you disagree with him, the guy is just a great writer. I don't think he's quite as good a speaker as he is a writer. I've seen him speak a few times. He was OK, but his writing is really nice.

Of all the different ways that you can sell the software that you have written, the way that I am going to talk about is a hosting service. Meaning that you never really ship the whole set of software to somebody. You might ship them a client up, but you mostly take the software you wrote...

By you I mean maybe you personally, maybe you personally are going to start a company, or a group of people together. There are about seven of us involved in the company that I'm going to talk about here. Still, it is small enough that if you can all fit in a room a lot smaller than this, it is much more personal of a company.

What we do is we sell the software as a hosted service. It is also called an application service provider. For some reason, that term was extremely popular in the late nineties. It is the same idea. A company called Salesforce.com seems to think that they invented the idea of selling software as a hosted service. People who are the age of my grandparents assure me that this is called a service bureau model. It was extremely popular in the first five years of mainframe computer use. It is not a new idea.

That's the way we decided to go with the software we wrote. I'm going to avoid talking about the industry or the customers or anything... I don't want this to become a spam talk. The software that we supply is of no value to anyone in this room. There is no way that any of you would ever possibly pay us a dime for this software.

It is for a specific narrow vertical market where there are tens or hundreds of possible customer companies. Those companies have very similar needs, but their needs are really not quite the same as any other industry. It is a vertical kind of thing. It is the kind of thing where many companies, if they are big enough, would do it as enterprise in house software. Some of our potential customers, that's what they're doing now. They hire consultants like us to come in and work on their software.

So, what is this software as a service thing? To figure out what it is, you can deconstruct the stuff that you deliver when you deliver software into these categories.

The most obvious thing you deliver with the software is the software. I put it on a CD-ROM and I sell it to you.

You also need to give somebody the right to use it. This is a legal licensure thing. Sometimes companies will license an application but instead of buying it as a permanent license, they will buy it as a three year license. I think Microsoft was generously provided the space does that for their big customers in their open license program. Is that what it's called?

So they sell you the right to use Microsoft Word on 10,000 computers for three years for some price. There's a separation of here's the physical software and here's the legal right to use the software.

But that's not all. There's also hosting. With something like Microsoft Word, you think that, well you have a computer, you should run Word on it. It's a Windows computer, could be a Mac.

But for the kind of, we sell enterprise software. I would guess that almost everybody in this room works on enterprise software. Anybody here who doesn't work on enterprise software in some way?

Yeah, see, we're an enterprise town. Running it, deploying it in a data center is a very important part of delivering software. If you work as a consultant, then you might be a consultant on a team writing some code - or anybody on another team writing code.

There's probably going to be another team, employees, consultants, whatever who work in the data center. They make the stuff actually run.

That can be an expensive part of providing software for some kinds of systems. For the kind of system we provide, that is true. Just chucking somebody the software, even if we gave them the software for free, they would still incur large costs in keeping it running and keeping it talking.

Big companies work with other big companies and they send complex information flows back and forth. Keeping all the systems up and running well is a lot of work. It's that hosting aspect. I divided that into both just the physical hosting and the support. The work to keep it running.

There's also support of the end users. You might have a system that has some centralized operation where there's a team of ops people who keep that running and then there's a couple 1,000 people out in the field using it in some way. Branch offices and the home offices and so on. Somebody's got to support them.

When we sell consulting, we unbundle all those things. When we sell commercial products, we'll bundle the first couple of them. Here's the software, here's the right to use it.

If you're Microsoft, I want to use Word for three years for 10,000 employees, what kind of price? You go to CompUSA, you pay 70 bucks for some fancy game. That gives you the permanent right to run that game on one computer. It's delivered to you in the form of a DVD-ROM in the box you take home and never really work them again. If they get lucky, you never place a single support call for that.

When you sell software that you put in a box at Best Buy, you better hope that most of your users never make any support calls. Because if, on average, they make support calls, then on average you're going to lose money on every sale. Because it's really expensive to provide the support.

When software is a service, you bundle more of that though. You don't only provide the software and the right to use it, you operate, your firm operates the service on servers in the data center on behalf of your customers. So you, in a sense, act as a proxy for them.

You end up even sometimes taking on their identity in working with their business partners. With their customers and their vendors. So an information flow that comes from some customer of theirs, really comes to you acting on their behalf, because you've taken that operations stuff in house.

You take the support of all that stuff in house. Those servers, if they break. So you buy the servers, you figure out what servers to buy. If they break, you fix them. If they don't seem to be working, you go figure out how to get them working again. You might even take phone calls from the customers' end users, that say 'hey, I can't get this to work on my computer.'

In my particular firm we don't do that part. So we leave that part with them. Our customers almost always have their own helpdesks just because of the business they're in. So their help desks take calls from the field from their field of end users. If they can't diagnose it then their help desk calls us.

But there are software as a service companies where you can do that. where you say , "Well you don't even need an IT shop at all." From a business perspective the software as a service offers something that MBA's get all excited when they hear about.

Anybody knows anybody, anybody have a business degree? A finance degree? Anything like that?

How do you feel about recurring revenues? Do you like those? The downside of recurring revenues is that you have to wait for them to recur. You know. If you sell somebody a package today, or even if you're Microsoft and you sell them a three year right to use Word for 10,000 people. You make the sale today, you get this big check today. That's really nice.

If you're providing software as a service you are almost always going to billing over time, over the time which it's used. In our case we charge a fee per user per month, there are people that charge a fee per user per year, there are people who charge per transaction, those are all things you can do. But all this is going to happen over time.

So your revenue doesn't look like the first thing, a nice big tall chunks of revenue coming in all at once. It looks more like the second graph, with revenue coming smoothly over time.

It's good because that means you have real sustainable cash flow to the business. It's bad because it is going to take a lot longer to recover your investment. So if you write a good piece of software and you sell outright. You might recover your investment with some number of initial big sales.

The software as a service, even if you make initial base sales, it is going to take a long time for the revenue to come in. So there is a greater investment with software as a service that you are making in terms of how much money you need to invest in it overtime to see if it works.

The downside of that, of course, is that those money flows might stop. Somebody writes you a check today for the hours you spent last week working, there's no risk you won't get paid. Your risk of not getting paid for your consulting work, is never more than a few weeks worth of risk, because you get paid shortly thereafter. If you build software on speculation and sell it outright, your team might work for six months and make a big sale and sell the whole thing outright. Even sell your company to a bigger company, recover your investment then.

With software as a service, your recovery of your investment is probably going to happen over a lot longer of a time period. That's the downside.

I don't want to talk to cheerleading. Adam's frowning at me. [laughter] He looks worried, worried at the lack of upfront revenue.

So that gradual arrival of those revenues, the fact that selling software as a service you get the money incrementally over time, that will end up shaping your operations considerably. How you spend money, you are going to find ways to spend money over time. Things like, "how can we defer writing some of the software to later?" I'll talk about that in a couple paragraphs here.

That's actually a really important part of it. What is the minimum amount of software I need to write to get the first few customers paying their per month fee, to get a ongoing business, to get some money starting to flow?

Let's talk about the hosting side of it a little.

Oh, by the way, I am going to try and keep my talk portion of my talk to something around 45 minutes, at most. And try to leave a lot of time around the end for discussion. I'm sure there will be many questions. I'm just kind of giving an overview of our experiences, I'm sure there will be a lot of what-do-you-do-about-that's.

Everyone here raise your hand for consultants. How many people are writing software consultants? How many help-make-the-systems-run consultants? One?

[laughter]

That's good because we are at code camp. Those guys are probably working this weekend. Because they are making some of those for over the weekend, so what do you do?

Man: Selling software as a service.

Kyle: All right, fantastic.

So you got to host this stuff. The nice thing about writing code and selling it is that running it is somebody else's problem. And if it's not running at three a.m. they are probably not going to call you. Now if you are inside a big company writing custom one off software, then they probably are going to call you.

But if you are an outside vendor? How many people call their outside vendor at three o' clock in the morning? It's very rare. Because if they have a problem, at three o' clock in the morning, it is probably a problem they are going to have to deal with in their data center. They are probably going to have to figure out why their Oracle instance is down. Any Oracle guys here? Since Oracle instances are never down?

[laughter]

Not for this project but for a different project we use Microsoft SQL Server, which is generally a great product; it is actually my second favorite Microsoft product. My favorite Microsoft products are their hardware actually. Microsoft mice are really great! I still have my original Microsoft natural keyboard. They stopped making the model I have something like ten years ago. It's fantastic! So Microsoft is a great hardware company. They're a great database company. Windows Vista, I have heard some less good things about.

But Microsoft SQL Server? Achieving 24/7 operations with Sequel Server is really hard. I have a feeling it may not be quite as hard to achieve that with Oracle, although I am not sure. I've never worked in a shop where we tried to make Oracle run 24/7.

If you are building software that the customer is going to want to keep running and available 24/7. That is a profoundly hard problem, and most companies simply punt on it. They build applications that can get in a state where getting them out of that state is a many hour offline operation. And that's no good. If you're under the gun from somebody else 24/7 and you are using tools are not really amenable to it? That can be really painful.

So more about hosting. If you are working in a big shop, you consult in a big shop. The application the code you write is probably being run two floors up or three offices over in an in house data center, right? That sounds familiar? Well I am talking about selling your software as a service from a small company because I operate small companies. You're not going to have a datacenter. And if you do have a data center it's going to be really awful.

This building is a great office space and great location; you actually might have been able to get redundant power and redundant networking connections in this building. In almost every building including probably all buildings I can see looking at this window, you can't, even if you wanted, get those things. You can't even if you wanted get those things. You can't get two incoming utility feeds coming in for power, you can't get three different ISPs coming into the building, you just can't do it.

The thing you need to do, if you are going to operate your own server, is go put them in a co-location facility, a hosting facility. It's not that expensive, it's $1,000 a month, which, of course, is a lot more money than a car costs. But compared to renting commercial office space, and getting multiple ISPs in? That's really not that much money.

For that you can get a full rack. You can probably get it for considerably less than that. I think we pay less than that, which is just a budgetary figure. You can get a full rack with quite a few servers in it, in a facility, it's going to have redundant power. It's probably going to have utility power coming into the building from two different directions. It's probably going to have a generator on the roof. It's probably going to have two maybe three different ISPs running connectivity.

I didn't mention in here, I didn't know I wanted to put it in print, but we're at Cybercon downtown in the Bandwidth Exchange Building. It's a grungy, nasty looking building.

[laughter]

It is completely full, it's full of power it's full of networking. I think every floor is packed with some kind of networking company on it. And we so far have been there about two years and have had zero downtime. We have not had a single moment when we have not had A/C power flowing into our rack and bandwidth working. That's good! I am really happy with that.

I have never been, I never had a customer who operates their own data center achieve that over a two year period. Even in my consulting work, we have had customers who have had very impressive hosting facilities where bad things happen. Phone guy trips over the wires on his way through. You have the downtime.

We've never had that where we are downtown. So I heartily recommend if you are going to sell your software as a service. You have to allay that customer's fear that he will have downtime. You might have your own downtime because your own servers break, your software breaks. But try to not have downtime because you didn't have power to network. So get your service somewhere where you will always have power and network.

You're going to host it for more than one customer, if you are at all successful at it. Any given customer would only host an instance through themselves. So you are in a position to get a lot more experience a lot faster hosting your software than anyone else could even if they bought unlimited enterprise license and hired their own people to run it. They would still only be running it for their company; you are going to be running it for all your customers.

You need to embrace hosting. You need to embrace things like being involved in operations. And get really good at them. Build things that automatically fail over, or that kind of thing. You need to figure out how to do backups and do a good job on backups. Make sure your backups actually restore.

The bad news is, is that stuff is a lot of work. The good news is, is that you can do a better job of it cheaper than your customers can, because your doing it for N instances of the same product. I think we have some number of identical servers, about the exact same server, from the exact same company. We put the same distro, the same OS on it. It's a lot easier to be good at administrating five identical things than five different things.

The full rack is a good way to go, if you can afford and if you need it. If you don't, then you can rent a part of a rack. You can pay for one server to be in a co-lo facility. You can pay for a virtual dedicated server, where you don't really get the physical server, but you pay - I think sometimes they're as little as 30-40 bucks a month.

Anybody here have a virtual dedicated server they use? OK, one. They're a pretty good way to go. You get a machine. It feels like it's a machine. It's not really a separate physical machine, but you have full administrative access to it. You're guaranteed some amount of RAM and some amount of CPU time. You can get the experience of operating your own equipment, even though you're not yet paying to operate your own equipment. So then it's a real easy step as you grow to go to a full real dedicated server. Then go to more than one real dedicated server. Then go to a rack full of servers. Then go to many racks of servers.

There's another approach I want to point out. I haven't done this yet. We've experimented with it. Experiment with it seems very appealing. Anybody heard of Amazon's S3 and EC2 services? Two. Pretty slick. Amazon EC2 is like a virtual dedicated server, but you can buy more of them anytime you want. You're going to API to buy more of them anytime you want.

So think about that. You can write a line of code, that when this code executes, you're going to be charged more money, but they're going to allocate a server for you for as long or as short a time as you want. So you can make an IP up that, "Yeah, but we need another server online now." They will transfer a virtual disk image over to a physical server, and it will boot, and it'll be yours to do with what you want. You can set it up for on boot, it some sense joins a cluster of other ones you already have booted. That's pretty slick.

If you could figure out many associated issues - there are many issues with that, like where to store the data and that kind of thing. When the server goes down, then it goes away. It's got to store the data somewhere else. The Amazon answer is on their S3 storage service, or on their Helium SQQ or something queuing service. You need to figure out those problems.

If you figured those out, you could have a highly scalable server farm that was there virtually on demand, where you didn't spend any money on hardware upfront, and you didn't sign any contracts for any dedicated servers for any amount of time. Yet you could sign up a new customer and determine that you need five dedicated servers to serve this customer, but in fact you only need those Monday through Friday, and on the weekends you only need one. You can actually buy that from Amazon, where your number of allocated servers, you could have your API allocate and de-allocate servers based on anything you want, or based on real-time demand on your system.

I have not built a system that works this way. I really want to. You could be selling your software as a service to an accounting firm, and in mid-April you could allocate a whole bunch more servers - anybody who works with an accounting firm knows that that happens - to run reports more quickly and churn through the data in parallel on more computers. Then it could go drop back down to the low level while everybody takes off a couple months later to try to recover.

The great thing about this is that your cost will follow that same curve. Buying this from Amazon is tremendously cheaper than buying ten racks full of computers and signing three year contracts on ten racks full of computers to stay allocated at that level permanently, which is also incredibly wasteful. It's even greater to do this because you're wasting energy if you buy this many servers and keep them spun up versus allocating them on demand.

Anybody have to take support calls from time to time? You guys don't count. You're doing the same thing I'm doing.

[laughter]

Anybody who works as a consultant get calls from the guys in the data center try to make the software your team wrote, work? No? OK. You haven't had the particular joy of them saying, "It doesn't work. We don't know why and we won't let you come look."

[laughter]

Man: But you have to fix it.

Kyle: "But you have to fix it now." The VP is on the phone. He sounds really angry.

[laughter]

With software as a service, they're your servers. You can service the customer much better because you don't have to have them talk you through how they configured the system you sold them. You have the same access or more access than they do. They can mostly likely access your service through the application you provided and you can access it through the application you provided. They may or may not be able to access it by running sequel queries against the database but you certainly can do that.

You can go look at the underlying system logs. Some of those system logs you might have exposed out to the customer but you can go look at the ones you haven't exposed yet to the customer. You can do a much better job supporting your server in this kind of model -- supporting your software as a service than you can supporting your software as something you ship. Of course, that's going to cost money to do.

We have a full time guy who provides support. The phone rings every once and a while. It doesn't really ring very often at all but when it does ring there is a guy to answer it. Well when a customer signs a big contract with you to pay you to provide this service for their zillions of users, they really expect to be able to make the phone call and get somebody who'll help them and so we provide that.

But I would argue that we can provide that much better than they could. They could hire someone to answer that call but their someone would maybe have only ever worked on posting one of these things once. Well we host them all. We could do a better job.

At the same time, you can learn how the customers use the system if they are using the system as a service that you are providing. We don't have to ask our customers how often they use certain features because they are using those features in our service. We can query or grep a log or something and find out how often they are using it. That's really nice. We can use that to learn how to do a better job meeting their needs.

We can notice that they are running a report all the time for one day at a time because the report only runs for one day at a time but they run it for a whole bunch of successive days. Without having to somehow elicit from them that that is causing them pain, you can realize hey this must be causing them pain. We built this one day report and they hired some guy to sit there and click on it for 90 consecutive days and then manually copy/paste them into Excel and make a quarterly report.

You might never have got that as a support request or as a feature request, but you can just see them doing it and you can add features that make their life better. Customers really like it when you add features that they didn't even ask for yet.

Now you have to add them and doesn't break anything because you break them by adding new features, they don't like that. But if you add a feature, a report that they used to have to run a day at a time, you notice that they're running it for many consecutive days, and you add the capability to extend out that date range, that's real good.

If your competitor is selling their software only as a packaged product, they'll never get the feedback. You can use the feedback that you can get to get better faster - be more agile than someone who is selling their software in a traditional model.

Paul Graham talks about this. He gives an anecdote and we haven't done this anecdote. His anecdote is that when his company was selling his SAAS it was called, well it became Yahoo! Stores.

Man: Viaweb.

Kyle: Viaweb. Yeah. When their competitors would add a feature and they get some press coverage of it. In the time it took for that to kind of work its way through the press process, they would add the feature and deploy it. So by the time someone came around to them to say "Hey, what do you think about your competitor having this great new feature?" They'd say, "Oh, yeah, we have that too."

[laughter]

That's because they didn't have to make a new release and then push it out there and get people to buy it and upgrade. They just upgraded the service. As long as it kept working in all the ways it worked before, there was nothing to stop them from just rolling it forward. We do one to two week iterations, occasionally three, of going all the way to production.

Anyone here doing Agile XP type stuff with short iterations? You usually don't go to production with your weekly iterations. We go to production every one to three weeks. You get really good... OK, so, the reason people get really worried about going to production so often is that you'll break things. Right? People are terrified -- the change control didn't review this yet?

If you do something often you get better at it. So because we go to production every one to three weeks we're really good at going to production every one to three weeks. So when someone needs an urgent fix, we can almost always put in the urgent fix without breaking anything because we've had, in the last year, between 15 and 20 times when we've gone to production, most of the time without breaking anything.

That is a much more, I'd argue, that's real agility in the sense that making a new iteration in a sort of fictionalized way within your team, but then being part of some bigger process that only gets into production every nine months, this is much more truly agile than that. You can do that when you're providing your software as a service instead of as some code.

Some of you looked at me funny on that. So I think that's going to be a topic of discussion at the end.

So what customers like about this stuff. They love not writing a big check before they start using the software, when they first start using the software. I see a nodding head over here selling SAAS. It's hard not to love not writing a big check but there's a question of why they love not writing the big check? And I'd say that even if they have the money just sitting there, they still reduce their own risk by not writing the big check.

Because if they buy software from you, and I'd say, even if you're Microsoft, the largest software vendor, or you're Oracle, and the company buys software from you, there's still a certain element of the unknown and the untrue in that purchase.

So even if I know that Oracle is the number one enterprise database, I still don't really know how well it's going to deploy in my organization. It might turn into a debacle even though it's known to be number one. There's this risk with unproven software.

With software as a service, a company can adopt it, and if they find in their first month of use that it's awful, they can un-adopt it and be out very, very little money because they were only going to pay for the software one month of usage at a time. They're only going to be out one month of usage of the software.

Now they'll still be out some other costs because they'll have had to do some things to adopt and help you work on some imports and some data flows and all that kind of stuff but the risk is far less to a customer in adopting it. And, I'd say, that that's a much more honest transfer of risk from the customer to the vendor than something like a money back guarantee.

Has anybody done the kind of marketing courses or anything? Money back guarantees -- take a guess what percentage of people ever take advantage of the money back guarantee? Yeah, it's really close to zero. That number is far lower than the number of people who are dissatisfied with their purchase.

So with a money back guarantee, if someone can get you to call up and give them your credit card number for five easy payments and buy the $400 exercise machine, the chances of you being dissatisfied are actually pretty high, but the chances of you actually executing on that guarantee and getting your money back are so close to zero.

Well customers aren't totally stupid. They know themselves to some extent. Right? People know that they probably won't return something. They probably won't execute on the money back guarantee. They also know that you might try to weasel out of the money back guarantee even if they decide they want to execute on it.

So by, instead, collecting the money a month at a time or whatever after they've used it, you've made that a real thing instead of a hypothetical thing. They just stop writing you checks and then they stop using the software. Much more of a real honest reduction of their risk than merely offering a money back.

In fact we don't even offer a money back guarantee. What we do offer is that we don't require a contract. You don't have to sign a three year agreement to use this thing. So yeah you can just start using it. If you want to stop using it, well if you really wanted to, I guess you could call and say we want to stop today, we will bill you for today and not for tomorrow. Or more likely you're going to decide a few months out because you've got to transition to something else, but we don't impose that on our customers.

Say, well, you know if you wanted a term contract you could have one -- if your guys have to have a number to write down how long the term is, the make something up, but we're not going to require that of you. You can quit tomorrow.

Customers don't tend to quit tomorrow, of course. Customers like the fact that you didn't even ask to hold them hostage, in a sense. You didn't even ask them for a multi-year commitment. You said, "Start using it. You can commit if you want, but we're not going to hold you to it."

The customers like not running the hosting operation. They especially like not hiring people to run the hosting operation. Now if you are in a big enough company, managers might be measuring their success by how many people are in their division, so they might actually prefer to run the hosting company.

But in the more typical case, people would really prefer not to have to go hire some operations people, not to have to handle the HR issues of having operations people, and so on. Not have to get those guys to be available at three AM if it breaks. They get to outsource all that to you and that is a pretty big benefit to them.

This idea that I showed here on the board for S3, that applies to what you can offer as well. With our products and service it kind of takes a little bit of work to get a new group of people in and out of it. So this can't be a one day period but it can be a few month period, certainly. So if our customers, if they win a new contract from their customers, then they will hire more people, and those people they hire will use the service that we provide and their costs will go up only for the length of time that they hire those people. If they lose that contract then they lay off the people that were meeting that contract and then theirs bill that they pay us drops proportionality.

Customers really like having their costs linked in that way -- in a smooth linear way -- to what they have to pay to run their operations. That's way different than -- even that example I gave of the Microsoft Open License -- I'm a big company. I do a Microsoft three year open license for 2,000 users of Word.

Well if I add another division and now I have 2,500 users of Word I got to go negotiate and they're probably going to try to get me to sign a three year term on a 3,000 user level or something like that.

No, they play this game with cell phones. You know, the cell phone ends up costing me almost nothing per minute to use, and yet, my bill is $100 because I have so many things that are sort of fixed -- there are so many fixed aspects of it.

There are all kinds of hybrid models where you can price software as a service but the way we price it in our organization is user per user per month. So if some of your users go away, then you just stop charging for it, at the end of the month or the end of the day or whatever.

Software as a service is an especially good sell to sort of the CFO, financial part of the organization, even if the IT, or operations part, of an organization is kind of uncomfortable with it. But it may make such strong financial sense, that even if the IT part of the organization is kind of uncomfortable with it, for some the reasons I'm going to discuss, that they buy it anyway, because they are in business to make money.

So what are some of those concerns? What do customers not like about it? Well customers tend to be concerned that they won't have as much control over the development and operations with something they buy as software as a service versus something they buy from hiring consultants.

The great thing about hiring some consultants, even in this organization we are standing in now, is you can call them up and when they get there you can say, "Write me a program to do X" and they'll eventually write you a program to do x. You don't have to, in a sense, sell them on writing you a program to do X because you are paying them to write whatever you ask them to write.

With software as a service, the customer can be worried that they might want something that you just don't want to sell. They want a feature that, let's make something up, what's an absurd feature? They want a feature where if you click the buttons in the wrong order, it corrupts the hard drive.

[laughter]

Let's make it a really bad feature. Well you might decide for your own business reasons that you're just not ever going to offer such a feature. In a sense, if that was really valuable to them, they've lost something because they've bought it from a vendor who will say no to some features instead of who will say yes to every feature.

And, I admit, we do occasionally say no to a feature. We don't say no to features very often because we really like our customers and we want to make systems that meet their needs. But every once in a while the customer can have a need, that for whatever reason, we don't want to meet in our software. We'll try to work with them and say, "Hey well you go do that in some other system and we'll try to provide an integration point" or something. I'm not saying you'd be obnoxious to your customers and say, "No, we won't do that."

But sometimes there's a feature they want that just they're not in your interest to provide and so you'll say, "Well we're not going to provide that in this product." If you want, you can talk to us or somebody else who does some consulting; we'll find some way to tie it in or something. Customers are uncomfortable that that's not quite as easy as if they hired some consultants to build them a system that they can just ask for stuff and those are the features that they'll maybe get.

Man 2: Well, that's true for small consulting on projects too, though. I mean, when they add e-commerce or something I'm comfortable adding that. I can do that for them.

Kyle: That's right.

Man 2: They might blow it off in a little while.

Kyle: That's right. I'm not saying these things are totally exclusive to the software service. But they're just things that especially come into the customer's mind. That software's a service. But they might not worry about that so much if they hire some consultants.

Man 2: That's true. They have the mindset that you pay somebody to do something, they're going to do it.

Kyle: Yeah, right. That's the mindset anyway. It's not strictly not quite true, but, yeah, it is a mindset. Another thing customers don't like. Potentially don't like. Just as it's nice to not write the big check up front, if you keep writing checks every month, you're eventually going to spend more than you would have, eventually, it may take a while, but eventually you're going to spend more than if you'd bought a comparable product that was available for an up-front fee.

Eventually, I mean, the payment goes on forever. Eventually, you're going to write checks that total, over time, even more than if you'd hired some consultants to build you a customer system, maybe. Customer don't like that, doesn't bother them so much in the beginning. But eventually on of those CFO-types goes and like runs a report in their accounting system and tallies up the total amount that they've spent since the beginning of time, sometimes, you know, they think about these four items here that I've listed, these five items that are part of providing software.

It may not occur to them that some of those costs were really, sort of operational costs that would have happened regardless of how they paid for the software but they just add up a number, right? And they run their report and they tally up and they go "Wow! That's a big number! I've paid this company a big number over the last N years. I probably could've like bought something off the shelf for less than that." Even though I'd argue that that's really, that's usually a false thing. It's very much a fallacy in almost all cases. But, it is a concern and it's an issue you... you need to address that.

We haven't been able to figure out how to address that too well yet. We've talked about trying to find ways to describe these various kinds of costs to help the customer understand that they're not only paying for a license.

So if this pie chart represents what they're paying it's easy for the customer to think of the pie chart like this. This is how much they're paying to license the software and this is how much is your profit.

[laughter]

OK? That's a fallacy, right? Because there's a lot of other costs. So all the money they're paying, and I have no idea how these wedges, these wedges are going to smear randomly by size, which is good because I don't have a video recording, only an audio recording.

[laughter]

There is going to be costs of hosting that some of the money goes to. There is going to be costs of operational, I'd say Human Resource requirements. Benji was saying, the cost of people to run the system. There is going to be the cost of some support, Human Resource.

Notice I haven't even put "running the software" yet, right. Well there's going to be some potentially very large part of the pie which pays for paying developers to keep working on the software today, OK? Because if you're selling your software as a service, you almost always have to keep working on it. You don't get to fire all your developers once you start selling it.

In fact, you generally will keep paying your developers, keep making it better, forever. Then there's some kind of recovery, right? So this is your costs of paying for people to keep working on the software while they're using it. Well, there's going to be costs that you're trying to recover the investment you made to work on software before they started paying you to use it. And that can be significant.

If you had a team of people spend three years getting software to the point where you can start selling it, you need a recovery on that investment, a return on that investment. You might eventually have some kind of profit. Or some peace.

[laughter]

And this is not to scale, right? Because in fact, in most cases you're not going to have such a slice at all and in fact this... you're going to have this as your investment recovery and that's not even fully covering recovering your investment yet. Really, it's be this big to cover your investment because you'd hoped to recover your investment by selling to many customers over years. And so we're trying to find some way to maybe communicate this idea to our customers.

So they understand that it's actually a pretty good value from the total cost compared to if they paid all these costs in cash as they happened. For example, customers, you know, they're somewhat aware, they may need to be reminded, that they didn't pay for the software to exist in the first place. They didn't start paying for it till they put their first user on it. But you had to do a lot of stuff before you even knew their names.

Man 3: And somewhere you need to add the business costs of the rest.

Kyle: Yeah, that's the recovery that...

Man 3: The risks that they're not paying....

Kyle: Oh, absolutely. Absolutely, yeah. Yeah, that's right, that's right. How many IT projects fail, right? I've been in organizations where, mysteriously, no projects that no one ever calls a project a failure, and yet everyone I knew at the organization had worked on, for the last several years, various other projects, none of which were ever made into deployment.

So they weren't called failures but, in fact, almost everything everybody worked on in the organization I was at never made it to production. If you're selling software as a service, or selling commercial software, I might just in the future call that commercial shrink-wrap software, you're taking that risk they're not. They're not paying for it until it actually works. It's like they don't even talk to you until your software actually works. And that's a huge benefit. What's next? Oh, go ahead.

Man 4: It seems to me that software maintenance isn't taken into account, a lot of times.

Kyle: That's right.

Man 4: This factors that in proportions too. You can get that for free or you can not get it.

Kyle: That's right, you might well say that the ongoing cost of having people work on the software, some of that is maintenance, fixing things, bugs, some is adding new features. When people are paying for software as a service, they tend to have a built-in assumption that the software should be getting better over time. Not that they're paying for a static piece of software. They get used to the idea that new features appear from time to time.

Well, what we do is we send out email summaries with our releases. You know, here are some problems we fixed, you've probably noticed. Of course, many will be problems that, we fixed them because they reported them. Or there'll be problems that we noticed that they hadn't even reported yet but because we can watch the logs of the running system because we host it we notice a problem and we fix it.

So we'll tell them, "Hey, we noticed that when this happens, this would fail, you hadn't told us, but yet we found it and fixed it. Oh, and we added these four new features." If you're hiring in a different model, if you're buying a consulting scenario, you'd be paying people to do all these things. If you're buying commercial, like up-front license software then you pay for the software which would be I guess this part. And then you'd pay some of your own people to host it, and you'd pay for the computer to host it, you'd pay for the people to support and host it and then you would pay a maintenance to the vendor that would typically give you fixes and then depending on that maintenance agreement you might have to also separately pay for upgrades.

You know, some vendors sell, you buy version two, you get maintenance on version two and you automatically get version three when it ships. Others, that's not the case. You pay for maintenance on version two, you maybe get a price break on upgrading to version three. Something like that.

Man 5: Your software features does that include where you're talking with your customers and deciding "Is this a new feature that they want, they want to add, you decide not to add it, or at least you're consulting, OK we can do that." Is that additional cost, do you charge extra for that?

Kyle: That happens to be a few more bullet points down. How's our time looking here? Been going about 50 minutes? Yeah, I should be able to finish in the hour I was hoping for. What's next?

Starting fast. If you're shipping software that the person expects to be able to use without your help you have to reach a certain critical mass of features before you can do that. Like, it has to be possible to configure it and start it running.

[aside] Some kind of debacle happening out here or something?

Man 6: Nah, it's just a noise. A chair, or...

Kyle: OK it's right down here. During my talk they're selling concrete or something.

So, there's this critical mass of features you have to have for a shrink-wrapped commercial piece of software to be even plausible for anyone to ever buy. It has to be possible to figure out how to install it. It has to be documented enough that you can figure out what command to type to make it turn on, that kind of thing.

Well, we built a big complex enterprise product. It would need to have, if we sold it as a shrink-wrapped commercial product, before we could make our first sale, we would have to have an enormously complex administration management section.

In fact, many enterprise-type applications sold commercially have many more screens of setup features than they do operational features. Those would all have to be in, at least, marginally working condition to start selling your product in a shrink-wrapped way.

With software as a service you can temporarily cover for the lack of those features by supplying more services. I mean human--people--kind of services. Since the customer doesn't have to ever install these server modules at all, you have the developer and like an operations guy that work together to get an instance up and running and if you do that you could easily do that for the first five or ten instances without it causing you really a whole lot of pain because you already know how to kind of hack around and get instances running in-house because you do it all the time for development and testing.

You can get a faster start with software as a service by not writing some of those features. We do not yet have an installer for the server side of our system because we don't need one. When we need new servers to serve users, we know how to do that in-house without needing a scripted installer-type thing. We'd rather have one but we spent those hours doing features customers need more instead.

There's a risk of starting fast, though, because you might not ever get around to adding those admin features. That's the caveat.

We did the fast start. We had very few admin features. Since then we've added a great number of admin features to our system. We have something like 30 or 40 screens worth of admin features now and we started with something like one screen of admin features. But we got real customers--human beings--using the system with one admin screen then we kind of faulted in more admin screens over time.

We would have had to sell our offering, in our case, as a shrink-wrapped commercial piece of software. We probably would've had to wait another year--maybe a year and a half--before getting our first dollar of revenue because the software would have had to have been much more complete. We started with a reasonably high quality but very small kernel of a system and started selling that and then kept adding from there.

But then how do we know which ones we need?

Man 2: They're the ones that hurt. [laughs]

Kyle: Well, yeah. There's the ones that the customers calls to have us do.

Man 2: Exactly.

Kyle: So, first example, when we very first started the customer had to call us to add some more users. So one of the most important features was to get where the customer could add and remove their users by clicking. So we added that one early on.

There are some other features where we get a phone call about them or an email about them once a year. We haven't gotten around to making an admin system for those yet.

So, what's it like to do this? I'm going to tell you about the subjective experience of it.

You have a much closer relationship with the customer. You didn't sell them one thing up front. You're involved with them. You're not in their organization like you would be as a consultant but you're involved, you're talking with people in the organization very frequently because you're in a sense operating part of their infrastructure for them.

It's really your infrastructure but in terms of business operations they think of it as their infrastructure, which they're paying a fee for you to provide, so you're involved with them in a much deeper way than you would be.

In fact, in some of my consulting projects we're less involved with our customer's operations than we are in this. In some of our consulting projects, we make software and then they have ops people that operate it. We're only kind of an arms-length relationship with them.

[cell phone rings]

So our software as a service is actually closer than a consulting type of relationship. Think about that. I asked how many people here that are doing consulting get involved with operations. I think there were only one or two hands out of--what?--maybe twenty people here. Every one of our developers is at least a little bit involved in operations.

It's a real different experience. Even when I've been in onsite consulting shops where I was down the hall from where operations happened and the group I was in was completely isolated from it.

Two more topics and I think I'm on track to get done what I want to.

Customizations--there's a question of what about when they want customizations that aren't really features you want to put in. Well, the purest in a sense thing to do is to, if it seems like a worthwhile feature that they want, then you make the investment to add the feature and then you charge more for having that feature.

There are other things you can do. You could say, hourly consulting for this customization. There's a derisive slang term of "consultingware." Consultingware is software which is so complex that you can't ever just buy it. Like SAP, for example...

[groaning, laughter]

...You spend a mountain of money to buy SAP and then--that's actually just the first of many large checks that you're going to write because then you bring in an army of consultants to make it do what you want.

Man 2: Then you uninstall it.

[laughter]

Kyle: In some cases.

Man 3: It's your business.

Kyle: It's your business. [laughs]

So, you can do that. I'd say there's a caveat with going in that direction with charging hourly for customizations. It's that the customer can get to thinking that they own the underlying product and it can be hard for your lawyers to even work out who owns what. The customer's going to think of it as work for hire. They pay for it by the hour. So you're going to have to deal with that. even if the contract says it's not work for hire in their mind, in their heart, it's work for hire. So, you're going to have to deal with that.

And so what we do with that we just kind of have persistent, polite, reminders in every conversation. We have this rule: You never have a conversation about them paying a fee for a customization without it being mentioned in that conversation. Remember, this is a host and service and this is going to be a customization that although you're going to pay for it, it's not going to be your thing because you don't own the code that it's a modification of. There's nothing you could possibly do with that without continuing to pay for our service.

You can do a hybrid thing--people pay like a fee for the customization and they pay a little more for the software, too. So you can do stuff in between.

The last thing is the intellectual property stuff. Depending on the tools you use, sometimes there's a little bit of a blurring as to what's code and what's data. In our system we have some business rules that are coded in JavaScript. So, in a talk I did a few months ago, they were stored in files or databases that are part of the application to do--I think, billing rules is what we used them for. That code is really part of the configuration data.

So, in a sense, those things are the customer's--those little snippets that give them their proprietary rule about how they're going to do their billing. But other than that, like the whole code the thing runs on, that's ours.

Since the data is the customer's--it's the customer's data--we provide and I would argue you should always offer this and try to get your customers to take this: They can get a dump--a backup, whatever--of the data underlying your system. So you have to make sure you build your system in a way so that the data is fairly well isolated from the code.

So if somebody says, "Hey, I'm not comfortable because I don't even have my data." You can say, "Well, you don't have your live data because you're paying us to operate your live system but if you want, we'll work something out to FTP over a backup from time to time or something and that can help them deal with some of the risks." That's one of the things: Make sure you get your lawyer to work out those details in your contracts.

Very last point--possibly the most important one here. Programmers make mistakes. But the mistake you must not make is giving one customer access to another customer's data. You must not do that. Every developer will have to be aware of that even though mistakenly that could actually be an offense that leads to them being terminated because if it happens once, the risk of the same person doing it again can be so high that you just cannot afford to take that risk. That is a mistake you must not make. I would say that if you have an unimportant little service like 37signals stuff like Basecamp, it's not quite that bad of a mistake. You're OK just using some WHERE clauses.

The kind of stuff we do, we use separate database instances. We will never have one database that has two customers' data in it and hope that our developers get the WHERE clauses right to never show you his data.

For big enough customers, I'd even say dedicated hardware. When you have customers big enough that you need more than one server to serve them, then consider partitioning so even if they're in the same physical rack, these three servers serve customer A, these five serve customer B, this one serves small customers A, B and C but it has separate databases on it.

Now, you have to do something different if you're one of these companies that's selling to a bunch of little buyers. We sell to a few big buyers. So, if it's a bunch of little buyers-something like the 37signals thing--then you have to just be really, really careful to use WHERE clauses on the same DBB, most likely.

OK, well that's the end of my prepared material. It looks like we have about 10-15 minutes. I don't know the exact time we're supposed to be done. Questions? Ideas? Share? Yeah?

Man 3: How do you deal with a potential customer who wants the option to purchase software?

[inaudible]

Kyle: My partner in all this has a saying that he says and that's not it. He said this before he had a wife and kids so I think it's probably not strictly true but other than wife and kids I kind of share his feeling on this. "Everything I own is for sale."

[laughter]

Kyle: "It's just a matter of the price. I love my house and I love the street I'm on, but there is a price for which I would sell you my house." I love selling my software as a service. There is a price for which I would sell you... I mean I would sell the whole company for the right figure and I would sell you an enterprise wide-side license for the right figure.

We had a customer ask that and we came up with a pretty high figure he thought, but the figure we thought was really pretty fair in terms of coming out good on the purchase. I think the customer was asking a little bit casually. They really weren't super eager to buy it now but they wanted to know that the option was on the table. I say the option should be on the table.

Now, it should be on there for only really big customers. For the little bitty customers, it wouldn't be worth us going to the effort to make it a reasonably good thing to shift to them for a small customer. But, for a big customer who really wanted to run it in house with their service and their people and so on, yeah we will come up with a price and we would probably have to bundle in some consulting hours to help them get it up and running. They would probably end up having to buy, oh what did I say? I said one of the parts of it is like a maintenance thing so they probably would have to find somebody to pay us for this.

So a curious result of our analysis is that if we were selling them our maintenance adding features and supporting the system, if we were selling those in the consulting mode and they already owned the hosting hardware and the right to use it, those wouldn't necessarily cost less than what we are charging for the whole bundle. It kind of makes sense because we are making an investment to grow our company by providing these things at probably less cost that you could write them.

If you just came to my consulting firm and you wanted get some really smart data guys on doing the maintenance and adding features to this big complex system that can cost a fair amount of money. That can easily cost more money than what we are charging the customers for use, depending on how they big they are.

For a big enough customer, it would be cheaper for them to buy it as a one time. For a small customer, a customer that has just a small number of users, they would spend tremendously more if they paid us for the software. Even if we gave them the software, they would still pay tremendously more for the consulting for each of these events. Yeah?

Man 2: Are you talking about including the source code or not?

Kyle: Everything I own is for sale, other than my wife and kids. Yeah?

Man 3: So if you got the smaller revenue stream coming in with no big payments, doesn't that drive the development offshore to 10 bucks an hour in India or whatever?

Kyle: We actually have a couple of people helping us out that are offshore. I don't think they are quite that inexpensive.

Man 3: You have a mix?

Kyle: Yeah we have a mix. I wouldn't say it does. I would say that no matter what you are selling, if you can buy the inputs at a lower cost, you probably will.

We certainly have more cost pressure. If we were charging out everybody on the project as a high rate consultant, we'd have a lot more latitude to pay high salaries for the work. Yeah, we've made some use of some offshore people who are, I would argue, just as worthy of human beings as all of us in this room and no less deserving of high quality, great work, environments.

Man 4: Kyle, the kind of software [inaudible]

Kyle: The product we sell is a big hairy complicated thing where they really couldn't do that effectively, but yeah, for products that are smaller, absolutely. I talk about 37signals and their Basecamp thing. You can get a 30-day free trial.

Man 4: So this is a good model to go to?

Kyle: Yeah, I would say it is. If you have a small piece of software or a small service you can easily do that with, that is a great way because it makes it even easier for the customer to try it out.

Man 2: What about, you mentioned giving your software away, do you think this will fit in well with open source solutions?

Kyle: OK. So that is another option. You can actually give away all this, right? And tell the customer, "If you want, you can pay us for this. You can pay us to do hosting operations and support and do a little maintenance but all the stuff and the features, and the big major companies, that going to be some people out there for free."

We don't think that's really a good way to go. We think that software is expensive to create and a very valuable thing once created, so I don't really see a lot of benefit in giving our stuff away. I think for infrastructure stuff there's probably a lot bigger argument for it. Something like the Linux kernel, where there's a horde of people out on the road that are fascinated and eager to work on it. We could open source our thing, and no one would work on it but us.

[laughter]

Red Hat brings in large profits, partly through the help of an army of volunteers.

Man 1: How do you provide customer training for when customers are on the road?

Kyle: OK, so the customer wants to bump up their usage, and they need to get more people. We don't want our costs to be very incremental on that, so we have a bunch of online stuff. Our website has a bunch of stuff on it. Then we have videos, computer screen videos, showing people how to use it. We send those to the customer. Sometimes we even print a nice label on a CD and send that out so they can hold something in their hand.

We do things to make it easier for our customers to train their people to use our product. By supplying the materials - we have a single price per user per month, and we provide that as part of it.

Man 1: You said that you guys are using definition of instances for their security for your customers?

Kyle: Yes.

Man 1: How do you recoup the costs, and do you have different pricing structures for different customers? For big customers, separate instance, but for small...?

Kyle: Oh, for separate hardware? No. That's just because the customer's paying a price per user. So a customer that has a lot of users is paying a much bigger check, and we can readily afford to dedicate some hardware for that. The customer that has only a very tiny number of users, we couldn't really afford to buy and maintain and host a whole computer just for them anyway, so they would have just another instance of the application on the same computer.

Man 2: Do you use an data encryption as a...?

Kyle: Data encryption. I'd say for the customers that are big enough that they're worried about the encryption of their data and accessibility on the same machine, they're going to be on dedicated hardware anyway.

So we're going to say, "Well, no, you don't have a passive encryption to your other company's data on the same hosting hardware. You're actually on a physically separate piece of hosting hardware." We wouldn't even commit to that in the contract if they asked for it. A big customer said we're going to have at least X number of users on your system. I'd say, "I'll tell you what. You're going to have at least X, we absolutely are going to have dedicated hardware for you."

Man 2: You run a four week production with these. Do you find that you're doing most of that with people who really know the code, or doing code reviews with a lot of people? Are you using automated regression testing? What's your biggest key?

Kyle: Yes, yes, and yes. We grew our team a lot at the beginning. Our team's winnowed back down to the small core of great people who really know the code. You have to do careful code review. You're going to put code in, it might break something for the customer who's paying you money to use it right now. So you've got to make sure you didn't break it.

We have, in some modules of our system, a really nice test suite. In other modules we have much less. We really ought to have much more with this suite. The fact that a customer wants to pay you to start using some software soon, totally changes your way of thinking about things like quality, right? If you can deliver value to the customer with worse code, it actually is rational to do that. Now, you don't want to do it too much. You'll introduce too much technical debt, and you're going to fall over, but it's a messy world.

I think we're to the end of our time. I'll take one more.

Man 1: Say, for example, you are going to give this product to your customer.

Man 4: Guys, we need your evals filled out please and turned in to me.

Kyle: We're in our last minute, so start filling out your evals, guys. What's your question? I'll answer it last.

Man 1: Say, for example, you've got a customer who already has some system, and they'd like to migrate to this. They have some data, and they want to migrate.

Kyle: You want to import data in?

Man 1: Yeah.

Kyle: For a big enough customer, we probably would do that, just to incent them to sign the contract. For a small customer, we might have to charge a fee. That's right. Sometimes it's a lot of work to import data. You might have to charge something for that.

Well, thanks everybody. We're at 10:30, so I'm done.