The History of SaaS

By Victor Hoang · Updated Oct 24, 2026

In January 1956, a US court entered a consent decree that told IBM how it could run its service bureau. That was the part of the company that processed other firms' accounting and statistical work for a fee. Most companies couldn't afford a computer. So they bought results from someone who had one. That's the oldest ancestor of Software as a Service (SaaS): you pay for the output, not the machine.

SaaS traces back to the 1950s and 1960s. Back then companies paid service bureaus and time-sharing firms to run their computing for them. The modern version arrived in 1999-2000, when Salesforce launched a customer-management product at an event called "The End of Software". The throughline is a change in who carries the work. First the vendor ran your computer, then your copy of the software, then one shared product for everyone.

Nobody called it software as a service then, and the rest of this page keeps the precursors apart from the model that came later.

Timeline at a Glance

The Service Bureau (1950s-1960s)

Companies buy answers from someone else's computer

Picture a payroll clerk in 1957 packing time cards into a box and sending them across town. A few days later a printed report comes back. The company never touches the machine, and doesn't want to. That was the service bureau. The Justice Department's own memorandum on the decree defines the business as preparing accounting, statistical and mathematical information and reports for others on a fee basis. The decree was entered on 25 January 1956, and its Section VIII let IBM keep a service bureau business as long as it ran through a separate subsidiary. The government said the aim was fair competition for independent bureaus. The expensive computers of the mainframe era were rare enough that renting results made sense.

Then someone proposed renting the machine's time instead of its output. At MIT's centennial in 1961, John McCarthy said, in a passage quoted in Technology Review, that "Computing may someday be organized as a public utility". He imagined subscribers paying only for the capacity they used. A SaaS invoice is that idea, delivered about forty years later.

This era solved access: a firm without a computer could still get computing. It left the customer with a fixed report, a delay and no direct control. The bigger step was to let the customer sit at a terminal.

What it means for teams today: Buying an outcome instead of owning the tool is an old choice. Ask which of your processes you should still run yourself and which you'd rather rent.

The Time-Sharing Years (1964-1980s)

Terminals, phone lines and rented computer time

Walk into an aerospace office in the late 1960s and you'd find a teletype wired by telephone to a computer in another city. The Computer History Museum's prehistory of cloud computing explains that users connected terminals to remote machines owned by a time-sharing company, and that these systems offered applications, services and data storage. The operating system rapidly switched among users, so each seemed to have a computer of their own. The author, David C. Brock, writes that much of today's cloud was prefigured in time-sharing. The mechanics of those systems are in the history of operating systems.

Tymshare is the clearest example. Two former General Electric employees founded it to serve aerospace companies. Ann Hardy, who had begun programming in the 1950s on IBM's Stretch supercomputer, joined in 1966 and rewrote a Berkeley operating system that wasn't built for commercial use. She went on to become a vice president and developed customer applications such as online banking and travel reservations, and she handled security because some users deliberately crashed the shared systems. By 1975 Tymshare handled about 450,000 interactive sessions a month, and its Tymnet network was larger than the ARPANET by the late 1970s. McDonnell Douglas acquired the company in 1984.

Here is the precursor in its strongest form. A vendor ran the hardware and applications, customers connected remotely, and everyone paid for use. It wasn't SaaS, though. The customer bought access to a machine's time, and the software was largely the customer's own program or a vendor tool on that vendor's single computer. Nothing was built from scratch as one product for thousands of separate companies.

The model faded as cheap computers moved onto desks. It left a lesson that SaaS vendors still learn: shared systems carry shared risk, and security is part of the product.

What it means for teams today: Any tool that holds many customers' data on common machines needs proof of isolation. Ask for it before you sign.

The ASP Boom (1998-2001)

Hosting old software over the new Internet

By 1999, with browsers everywhere, the idea came back as a business plan. USinternetworking was incorporated in January 1998 and, in its December 1999 S-1, called itself a "facilities-based application service provider". Its pitch was to host other vendors' business applications in its data centers and charge a monthly fee. The filing reports 81 signed contracts with 64 clients as of 30 September 1999, and revenue of $20.9 million for the first nine months of that year, up from $4.1 million between inception and the end of 1998. About 16% of that revenue came from SiebelNet, a subsidiary of Siebel Systems. The same moment is part of the dot-com bubble.

Then came the reckoning. In October 2001 Jennifer Mears wrote in Network World, republished by Computerworld, that ASPs had rushed in "in droves" and that Dataquest had forecast revenue above $22 billion by 2003. Gartner's estimate for 2000 was $2.1 billion. The reasons she lists for the shortfall are specific. Many ASPs lacked workable business plans or funding, and an analyst said most "tried to be everything to everybody". Hosting client/server applications over the Internet raised security, latency and integration worries. Big companies wanted customization that ASPs wouldn't provide cheaply, and building data centers consumed cash before recurring revenue could repay the debt. USinternetworking itself had laid off staff and stopped building data centers.

The distinction matters. ASPs ran software that had been built to be installed, one customer at a time. That's hosting. The winners rebuilt the software itself.

What it means for teams today: Moving an old process online isn't the same as redesigning it. If a vendor's cloud product is just last decade's install running on someone else's server, expect the same upgrade pain.

The End of Software (1999-2010)

Salesforce, NetSuite and the browser as the whole product

This era overlaps the ASP boom, because the winners started at the same time with a different plan. According to Salesforce's own history, the company set out in February 1999 to be "A World-Class Internet Company for Sales Force Automation" and incorporated on 8 March 1999. Marc Benioff, Parker Harris, Frank Dominguez and Dave Moellenhoff started on the first version in a rented apartment on Telegraph Hill in San Francisco. On 7 February 2000 salesforce.com launched at a San Francisco event called "The End of Software", with 1,500 attendees. A month later it staged a mock protest outside a Siebel Systems conference, and the stunt won coverage in The Wall Street Journal. By 2001 it counted more than 3,000 customers.

The same year as USinternetworking, an accounting-software company was incorporated in California. It later became NetSuite. Its 2007 IPO filing describes delivering a business suite "over the Internet as a subscription service" under a "software-as-a-service or on-demand model", for over 5,300 active customers and $67.2 million of 2006 revenue. Its chairman and chief technology officer was Evan Goldberg. The label had settled: by then the filing used "SaaS" as an ordinary industry term.

Salesforce went public on 23 June 2004, raising $110 million at $11 a share, and in September 2005 launched AppExchange so outside developers could sell applications to its customers. The broader infrastructure shift that made all this cheaper, including Amazon's storage and server rentals from 2006, is told in the history of cloud computing, and the interfaces that let products connect are in the history of APIs.

The era solved installation and upgrades, because customers just logged in. It created a new problem: the vendor now owned the customer's data and the renewal date, which is why SaaS pricing models became a field of their own.

What it means for teams today: Subscription software converts a purchase into a relationship. Ask what happens to your data and your price at renewal before you pick the tool.

The Self-Service Turn (2002-2019)

Customers try it first and sales arrives later

Atlassian was founded in 2002 to help software teams work better together. Its 2015 F-1 is blunt about the model: "We do not have a direct salesforce." It describes selling online through a self-service, low-friction approach, relying on word of mouth and low-touch demand generation, and it reports more than 51,000 customers in over 160 countries. That's a different kind of SaaS company from the one with 1,500 people at a launch event, and it's the base of today's product-led growth strategy and freemium business models.

SaaS also split into industries. Veeva's 2013 S-1 says it was incorporated in January 2007 as Verticals onDemand and renamed in April 2009. It describes itself as a provider of industry-specific, cloud-based software for life sciences, with about 170 customers by 31 August 2013, including 33 of the 50 largest pharmaceutical companies. The filing also says substantial portions of its CRM product are built on Salesforce's platform.

The new problems were sprawl and the cost of finding customers one at a time. If you're measuring that business, the B2B SaaS growth model is the practical companion.

What it means for teams today: Letting people use the product before they talk to sales changes who the buyer is. Plan for a bottom-up user and a top-down purchaser.

The Age of Agents (2022-present)

Software stops waiting for a click

Salesforce's 17 September 2024 Dreamforce announcements introduced Agentforce as a suite of autonomous AI agents for service, sales, marketing and commerce tasks. For the first time, the product doesn't only record work; it attempts some of it. Pricing follows the same drift. Intercom's pricing page says its Fin AI agent is priced "per outcome", not by the seat. The cost basis moves from people using the software to results the software produces, a visible shift away from the per-seat subscription. How teams are adjusting is covered in usage-based pricing and how AI reshapes the SaaS operating model.

This chapter is still being written, and it's too early to say which models will last.

What it means for teams today: When a vendor prices by outcome, define what counts as one before you sign.

Key People

Key Facts

Key Facts: SaaS History

• A 1956 consent decree let IBM run its service bureau business through a separate subsidiary, per the Justice Department.
• Tymshare handled about 450,000 interactive sessions a month by 1975, per the Computer History Museum.
• Gartner estimated ASP revenue at $2.1 billion in 2000, against a Dataquest forecast above $22 billion by 2003, per Network World.
• Salesforce launched on 7 February 2000 and raised $110 million in its 23 June 2004 IPO, per its own history.
• NetSuite had over 5,300 active customers when it filed for its IPO, per its S-1.
• Atlassian reported more than 51,000 customers with no direct salesforce, per its F-1.

The Pattern Behind the History

Across seventy years, SaaS climbs four rungs. We call it the Delivery Ladder. It's our own synthesis of the sources above, not a published study.

1. Sell the result. Service bureaus gave customers reports and kept the machine.
2. Share the machine. Time-sharing let many customers use one computer remotely.
3. Host the software. ASPs ran installed software for customers, and most stalled.
4. Build it for everyone at once. Salesforce, NetSuite and the self-service companies built one product on shared infrastructure, then let customers try it before buying.

Each rung moved more of the work to the vendor, and the next one asked what the customer really pays for.

What It Teaches Teams Today

• Hosting isn't redesign. The ASPs failed partly because they moved old software without changing it. Check whether a vendor rebuilt its product or just rehosted it.
• Shared systems need proof of isolation. Time-sharing taught this in the 1960s. Ask where your data sits.
• The timing of the network matters. McCarthy's idea waited decades for browsers and broadband. Good ideas need the enabling change.
• The seller's model shapes the product. Atlassian's no-salesforce choice forced a product people could adopt alone. Look at how a vendor sells before you judge the tool.
• Read the pricing unit. Seat, usage and outcome pricing each shift risk between you and the vendor.

For the wider story of the network underneath all of this, see the history of the Internet.

SaaS didn't arrive in a single year. It's what remained after service bureaus, time-sharing and hosted software each solved part of the problem, and the next rung is the one teams are standing on now.