Turning a service business into software can make sense when customers need a recurring outcome and enough of the work follows a process you can make repeatable. Before investing in a build, though, you need to understand whether customers would pay for an offer that asks them to take on some of the work you currently do for them.
Your existing business gives you somewhere to begin that investigation. You already know people who pay for help, and you may have developed a spreadsheet your team relies on or an internal tool clients keep asking to use. When something has become useful enough that people want access to it, exploring a product is a reasonable next step.
The harder part is accounting for everything you do around the tool.
Perhaps the spreadsheet works because someone on your team checks the information before entering it, sometimes after chasing a client who has missed the deadline. A recommendation that looks right on paper may need another look because you know something about the business that changes your advice. None of that necessarily rules out software, but it does affect what you can promise customers and how much help they will need.
Before deciding what to build, you need a clearer picture of the work the proposed product would take on and the work that would remain with you or move to the customer.
Productized service vs. SaaS: what are you actually selling?
A productized service packages a service into a standardized offer for a defined customer, usually with an established scope and price. Your team still performs the work, but customers have a clearer understanding of what they are buying and how it will be delivered. Precursive’s guidance describes this approach as making services predictable and repeatable.
Software as a service, or SaaS, gives customers access to hosted software. That can still involve considerable human assistance. Stripe distinguishes low-touch models from high-touch businesses that help customers purchase, implement, and use the product, so you do not have to make an offer entirely self-service for it to qualify as SaaS.
These arrangements place different responsibilities on your business and your customers. Before choosing a build, consider which one you want to offer and what would have to change in your current delivery model to support it.
You may find that improving an internal tool would make the service business more efficient without giving customers direct access at all. Giving them their own login introduces questions about what they can reasonably manage and what they will expect you to handle when they need help
What are clients paying you to do?
Consider a fictional operations consultant who helps small agencies plan staffing.
Her spreadsheet combines project deadlines, team availability, and expected revenue. Each month, she helps clients decide whether to hire or use contractors.
It seems software-ready. The formulas work, and clients are big fans of the dashboard.
During those monthly calls, though, she does things that never make it into a cell. She knows to challenge a project estimate because the client has underestimated the same work twice before. She asks whether someone’s availability accounts for parental leave. The list goes on.
Handing over the spreadsheet wouldn’t hand over that, say it with me, human judgment.
To find out what your own service contains, start by reviewing recent engagements. Record the information you had to correct and the decisions clients expected you to make, paying special attention to exceptions that crop up. What happened when the usual process didn’t fit?
And be specific.
“Strategic oversight” tells you little about a product requirement, especially when compared to “Checking whether projected revenue is contracted before recommending a hire” (which really gives you something to work with).
You might be able to make that check explicit in the product or you might decide it still needs a conversation.
Which parts could become a repeatable product?
Our consultant might discover that operations leads can maintain an accurate capacity forecast after an initial setup session. They still want advice when deciding whether to hire, but they no longer need her to prepare the same report every month.
That gives her a more specific offer to investigate than turning the consultancy as a whole into software. It also leaves room for customers to continue buying advice.
She would then need to understand how well that division of responsibility works in practice. An operations lead might be comfortable updating the forecast but struggle to recognize when the information is incomplete. A project delay halfway through the month could reveal that the customer does not understand how a change affects the forecast.
Those difficulties would require investigation before she could decide how to address them. Better onboarding might resolve one, while another could expose a product limitation or a service customers will continue to need.
Keep a record of the assistance you provide during this period. Early manual work can help you understand what the product should accommodate, provided you account for the time it takes. It becomes a budgeting problem when the business assumes that work will disappear without establishing what would make that possible.
Stripe’s high-touch SaaS model makes room for ongoing assistance. If your offer needs that level of involvement, you need to understand the cost and organize the service accordingly.
Would your existing clients buy the software?
A client who pays you to handle staffing may have no desire to maintain staffing software. They may value your service precisely because it gives them one less responsibility.
Another client might welcome more control but expect your advice to remain included. A smaller agency that cannot afford the consultancy could be interested in the tool, although you would need to learn whether its workflow resembles the one you already understand.
Each conversation concerns a different offer, so a general question about whether someone would “use the software” is unlikely to tell you enough.
Explain what the proposed product would do, what the customer would need to manage, and what help would be included. Put a price on an offer you can credibly deliver, then investigate how they respond.
If a client wants access, find out who would use it and whether that person has time to keep the information current. If they expect you to be available whenever a forecast looks worrying, work through what that obligation would involve before including it in the price.
“You should sell this” is encouraging to hear from a client. Giving them a specific offer to consider will help you understand whether their enthusiasm extends to buying it and taking on the responsibilities it requires.
What Basecamp and Mailchimp actually demonstrate
Basecamp began inside 37signals, which was then a design firm. The team needed a better way to manage projects and communicate with clients, so it built one.
According to co-founder Jason Fried, clients began asking whether they could use the system for their own projects, and the founders adapted it for sale. About a year after its release, Basecamp generated more revenue than the web-design business, which they then stopped operating.
Those clients had encountered the tool through actual work before asking to use it elsewhere. Their interest gave the founders something more informative than praise for a demo, although they still had to release a commercial product to establish whether it could support a business.
Mailchimp illustrates another route. Its founders ran Rocket Science Group, a web-design agency serving large corporate clients, while developing an email-marketing service for small businesses. The software served a customer group the agency was not primarily working with.
These histories show how software businesses can emerge alongside service businesses. They cannot tell you which parts of your own service will transfer successfully or whether your existing clients should be the product’s first customers. Those questions need evidence from the offer you are considering.
Can the service business support the experiment?
Client revenue might help fund development, but it also pays for obligations that continue while you explore the product.
Before committing, work out how much cash and time the business can spare without weakening current delivery. Include your own role in that assessment. If the plan assumes you will keep selling, serving clients, and managing the team while also making product decisions, it needs to explain where that additional capacity will come from.
Write down:
- How much you can invest without compromising the service business.
- Who will own product decisions and respond to customer questions.
- What work will stop or reduce to make that capacity available.
- What you need the next investment to establish.
- When you will review the evidence and decide whether to continue.
Pay attention to any work the service team takes on to keep the product useful. A product that depends on their involvement may still be worth selling, but its price and staffing need to reflect that arrangement.
You do not have to abandon the existing business to explore software. You do need to account for the attention the experiment will require, especially if the same people are responsible for keeping both moving.
What should you test before building?
Choose a recurring task and describe what a customer should be able to accomplish with the proposed offer.
For the fictional consultant, that might mean an agency operations lead can update project and team information, identify a likely capacity shortfall, and explain the assumptions behind it without the consultant preparing the report.
That description gives her something to observe. A spreadsheet or lightweight prototype may be enough to begin, provided it allows the customer to attempt the task without someone quietly doing the difficult parts for them.
During the test, record where customers need help and what that help involves. If someone cannot interpret the forecast, note what they misunderstood and what you had to explain. If you correct their information before they can proceed, keep track of why the correction was necessary.The following record is a practical exercise for the test, rather than a validated scoring system:
Decide beforehand what the test will inform. You might be weighing a narrow build, investigating whether paid onboarding would be enough, or deciding whether the tool should remain internal.
Be careful about how much you conclude from each result. A successful demonstration may justify another experiment, while repeated use with manageable support gives you evidence about whether customers can continue using the offer. Payment adds commercial evidence, but you will still need to understand whether you can reach and serve more customers on comparable terms.
Leave room for a result that changes the plan. If clients consistently need your interpretation before the output becomes useful, that work deserves a place in the offer and its price. It may also give you reason to reconsider whether a standalone product is the right direction.
Bring the business decision to the Decision Lab
Software could become a new source of revenue, but developing it will require resources from the service business you have already built. Before the roadmap gets detailed, decide what you are prepared to commit and what you need to learn before investing further.
If you are weighing that move, bring the proposed offer and any customer evidence you have to Coura’s Decision Lab, our monthly decision cohort. We’ll work through the decision with the whole business in view, including the work you want to keep delivering and the tradeoffs you are willing to make.Explore the Decision Lab.
Frequently asked questions
Is a productized service the same as SaaS?
No. A productized service standardizes a service offering that people still deliver. SaaS provides access to hosted software, sometimes alongside implementation or ongoing services. Charging a subscription does not, by itself, distinguish the two.
Does service revenue validate a software product?
Service revenue shows that customers will pay for the service you currently provide. You still need to investigate whether they would buy the proposed software offer and get enough value from it with the assistance you plan to include.
Can you sell software and consulting together?
Yes, provided customers understand what each includes and the price accounts for the work involved. If customers need substantial implementation help or ongoing advice, those delivery costs belong in the business model.
Should you stop client work before launching software?
There is no universal requirement to do so. Basecamp and Mailchimp originated alongside agency businesses, but their histories do not establish the right timing for yours. That decision should reflect the resources you have available and the evidence you have gathered about the product.