Perspective
We Were Building RaaS Before It Had a Name
Three years of building. Years of customer feedback. In March 2026, Sequoia independently described the same shift: sell the work, not the tool.
By Calvin Brown · Published September 18, 2026 · 10:58 AM ET
On March 5, 2026, Julien Bek of Sequoia Capital published "Services: The New Software." It opens with a claim that is easy to misquote and important to get right:
The next $1T company will be a software company masquerading as a services firm.
That is not a prediction that Results-as-a-Service is a trillion-dollar market. Sequoia never uses the terms RaaS or Results-as-a-Service. It describes autopilots: companies that sell completed work instead of tools.
The reasoning is economic. Sequoia writes that every founder building an AI tool is asking the same question: "what happens when the next version of Claude makes my product a feature?" If you sell the tool, you are in a race against the model. If you sell the work, every improvement in the model can make the service faster, cheaper and harder to compete with.
Their accounting example is the simplest version of the argument. A company might spend $10K a year for QuickBooks and $120K on an accountant to close the books. The next legendary company will just close the books.
Sequoia puts the product distinction in one line:
A copilot sells the tool. An autopilot sells the work.
And it argues the work budget is substantially larger: for every dollar spent on software, six are spent on services.
Some of the market now discusses this shift as Results-as-a-Service, or RaaS. That is our language, not Sequoia's.
At SweetGum.ai, we didn't start with either label.
We started building toward that operating model roughly three years ago — well before Sequoia published this thesis.
That does not mean we invented the category. It does mean we were pursuing the same operating model before this essay existed, and before we called it RaaS. Long before the labels caught up, we were asking a different question about software:
Why are we giving businesses more tools when what they really need is more work getting done?
Software shouldn't just be something you use
Traditional SaaS gives a company software.
The customer logs in. Someone learns the system. Someone configures it. Someone manages it. Employees still have to perform the underlying work.
We began approaching the problem differently.
Instead of asking, "What software does this company need?" we started asking:
What does this company need done?
A plumber doesn't wake up wanting field-service software.
They want calls answered. Appointments scheduled. Estimates accepted. Customers reminded. Technicians dispatched. Payments collected. Reviews requested. Customers brought back.
A roadside-assistance company doesn't necessarily want another dashboard.
It needs customers to understand pricing before service, provide identification, accept terms, pay before dispatch, receive updates and have documentation available when a charge is later disputed.
A retailer doesn't want another technology platform.
It wants customers to buy.
Once you understand the difference, the product you build changes completely.
We started thinking of software as an employee
One of the ideas at the center of SweetGum has become:
Your app should work like another employee.
Not another icon.
Not another dashboard.
Not another piece of software your employees have to manage.
An employee.
One that can work 24/7.
It can answer customers. Take appointments. Accept payments. Send reminders. Dispatch workers. Sell products. Collect information. Issue promotions. Follow up with customers and execute parts of the company's operating process.
That's an important distinction because the value isn't ultimately in the software.
The value is in the work the software gets done.
That maps almost directly onto Sequoia's stack:
Traditional SaaS: here is software your employee can use.
AI copilot: here is AI that makes your employee more productive.
Sequoia's autopilot: we'll perform the work for you.
SweetGum's RaaS: your app becomes another employee whose job is to produce the result.
Sequoia notes that for every dollar spent on software, six dollars are spent on services — and that the addressable market for autopilots is labor spend, insourced and outsourced combined. One vertical it flags is especially close to the businesses we serve: IT managed services, a $100B+ opportunity. Existing software, Sequoia writes, sells tools to the managed-service provider. Nobody has yet sold "your IT runs" directly to the company as an outcome.
That is the same question we have been asking of plumbers, retailers and roadside-assistance companies. Don't ask what features the app has. Ask what work this employee can do.
We believe that transition is already underway.
We've spent the last three years building for it.
We had customers before we had the category
There's another important difference between discovering a trend and building one:
customer feedback.
SweetGum hasn't spent three years developing this idea solely on a whiteboard.
We've put software into businesses.
We've watched people use it.
We've watched them not use it.
We've learned where customers get confused, where business owners still intervene manually, which workflows people avoid, what customers expect from mobile experiences and what actually saves an owner time.
That feedback changed the product.
It also changed our thinking.
We realized that successful software for small and mid-sized businesses couldn't simply digitize the company.
It needed to understand the company.
That's why SweetGum's model isn't about giving every business the exact same generic application.
Businesses may share infrastructure and common industry workflows, but every company has something that makes it them.
Their pricing.
Their customer experience.
Their operating rules.
Their services.
Their personality.
Their competitive advantage.
We want the technology to preserve those differences while automating the work surrounding them.
Then AI changed the economics
The arrival of increasingly capable AI models didn't create this strategy for SweetGum.
It accelerated it.
AI now gives us the ability to turn more of the judgment, communication and repetitive operational work surrounding a business into software-driven execution.
Sequoia's Claude question is the reason that matters. If the product is only a tool, the next model can collapse it into a feature. If the product is the work, model improvements can make delivering the outcome cheaper and faster rather than wiping the company out.
Sequoia also describes a transition between intelligence and judgment: writing code is mostly intelligence; knowing what to build next is judgment developed through experience. As AI absorbs more intelligence-heavy work, human judgment becomes more valuable, while the system handles more of the execution.
For SweetGum, that creates an enormous opportunity.
We bring decades of enterprise architecture and consulting experience into the AI era and ask:
What parts of running this company can technology now do for the owner?
That's different from simply attaching an LLM to existing SaaS.
It's also why our history matters.
Our founder is unusually suited to this moment
SweetGum founder Calvin Brown has spent more than 25 years building technology and solving business problems, including work across enterprise consulting, logistics, transportation, government, retail, mobile applications and cloud architecture.
That background creates an unusual combination for this particular market.
The challenge of Results-as-a-Service isn't simply knowing how to use AI.
It's knowing what should be built, what should be automated, what should remain human and how the pieces fit into a real operating business.
Sequoia makes a similar distinction: writing code increasingly becomes an intelligence problem, while deciding what should be built remains a problem of judgment developed through experience.
That distinction is central to SweetGum.
AI can dramatically increase how quickly we produce technology.
Twenty-five years of experience helps determine what technology is worth producing.
The last 8–10 weeks have been another experiment
Over approximately the last 8–10 weeks, we've taken this message directly to the market through Instagram.
Not simply through advertising.
Through stories.
We've shown businesses what we see when we look at their operations. We've identified problems, explained how technology could address them and, in some cases, begun designing the solution before the business ever asked us to.
That has become part of what we call our Storify approach.
Find the business.
Understand the story.
Identify the friction.
Show the technology.
Demonstrate the result.
Instead of telling the market what AI might eventually do for small businesses, we're showing businesses what it can do for them right now.
And the response is helping us refine the model again.
We already made the pivot others are beginning to describe
This may be the most important part of our story.
SweetGum didn't begin changing direction because a venture firm published a thesis about the future of software.
We had already made the pivot.
Sequoia published its essay in March 2026. Our stated history puts the development of this model roughly three years earlier. That is a defensible timeline, not a claim that we invented Results-as-a-Service. The concept has broader antecedents. What we can say accurately is that we were pursuing this operating model before Sequoia published the thesis — and before we were calling it RaaS.
We had already begun moving from building software businesses could use toward building technology that could perform meaningful parts of the business itself.
We had already started describing apps as employees.
We had already begun building shared industry infrastructure that could be customized around what makes an individual company unique.
We had already started using AI to accelerate the creation and adaptation of those systems.
And most importantly, we already had years of customer interaction informing what worked and what didn't.
The terminology caught up later.
From SaaS to RaaS
For roughly two decades, SaaS asked:
What software can we sell this company?
The next era asks:
What result can we deliver this company?
That sounds like a subtle change.
It isn't.
It changes the product.
It changes pricing.
It changes the addressable market.
It changes the relationship between the technology company and its customer.
And it changes what the customer should expect from software.
Sequoia predicts the next $1 trillion company will be a software company masquerading as a services firm. That is remarkably close to the Results-as-a-Service model we have been building at SweetGum for the last three years: crossing the boundary between software and services by selling the outcome rather than merely the tool used to produce it.
We agree.
We just arrived at the conclusion by building.
We're not following this thesis. We arrived at it by building.
There will be many companies entering outcome-based software — what we call Results-as-a-Service — over the next several years.
Some will begin with AI and search for industries where it can be applied. Sequoia expects many 2025 copilots to try becoming autopilots in 2026, and notes the opening that creates for companies that started by selling the work.
SweetGum came from the opposite direction.
We spent decades inside businesses.
We learned how companies operate.
We built enterprise systems.
Then we spent the last three years turning that experience into a platform capable of giving individual businesses technology that doesn't merely represent them — it works for them.
We were doing it before we called it RaaS.
We were learning from customers before this thesis was published.
And we're continuing to evolve the model in public as the rest of the technology industry begins recognizing the same shift.
We don't view SweetGum as a company chasing a market Sequoia named.
We spent three years building toward an outcome-based software model. In March 2026, Sequoia independently articulated essentially the same macroeconomic shift.
And after three years of building, customer feedback and iteration, we're not starting from a thesis.
We're starting from experience.