I didn't wake up with a perfect SaaS idea. I kept doing the same step for different clients: turning a messy folder of notes into a clean weekly status update. Eventually I noticed the repeated work had a shape and a few clients were willing to try the same tool.

Service work can be a great way to learn a market and fund early product development. The trap is assuming that every repeated task should become software. Some work is valuable precisely because a human is doing the thinking.

Look for repetition, not just annoyance

After each client project, write down the steps you repeated, the inputs you needed, and the decisions you made. Notice which part is stable and which part changes. If you make the same spreadsheet each week but the hard part is interpreting a different business situation, the spreadsheet may not be the product.

Ask the client how often the task happens, who owns it, what goes wrong, and what they do after you deliver it. Look for a consistent job that multiple people describe in similar words. One client can reveal a good hypothesis; a few more can help test whether it travels.

A consultant and founder map a repeatable client process together

Separate the service from the software

Draw two columns: “human judgment” and “repeatable steps.” The human column may include recommendations, complex exceptions, taste, and context. The repeatable column may include importing information, reminding someone, formatting a report, or creating a first draft.

Build around the repeatable slice first. You can keep offering the expert service for decisions that need a person. This hybrid can be more honest and profitable than pretending the software automates everything. It also gives you a way to learn what the product should support over time.

Sell the pilot before building a platform

Offer one clear outcome to a few existing customers. For example, “I can prepare and send a weekly project brief from the updates your team already shares.” Be explicit about what's manual and what's automated. Charge for the result if it has real value, and ask what would make it easier to use again.

Your first version can be a script, a spreadsheet, or a small internal tool. Don't build dashboards for an imagined enterprise buyer before you know whether someone wants the result twice. A manual step is fine during discovery as long as you aren't misleading the customer about what the product does.

Design the boundary around exceptions

Write down what the tool should do when information is missing or contradictory. Can it ask the user? Should it create a draft for review? Does the work stop when something touches money, legal terms, or an external message? The boundary is part of the product promise.

Over time, turn frequent exceptions into product features only when they remain understandable and safe. Keep unusual cases in a human queue. You don't have to eliminate every exception to create a useful SaaS.

Make the business transition gradual

Keep enough service revenue to support your runway while you test the software. Set aside real build time; otherwise client work will consume the calendar and the product will stay an after-hours wish. Decide what client work you will stop taking when the product has enough evidence.

Be careful not to overfit the product to your first client. Their needs are real, but they are not the whole market. Ask whether another customer would pay for the same outcome, and what would need to change for them to adopt it.

A practical productization check

  1. Find one repeated task across several client engagements.
  2. Separate the stable steps from the expert judgment.
  3. Offer a paid, clearly scoped pilot for the result.
  4. Build only the repeatable part and keep a safe human fallback.
  5. Test whether another customer values the same outcome.

You don't have to choose between a service and software on day one. Use the service to understand the work, use a small product to reduce the repeatable friction, and let customer behavior tell you whether the slice is ready to stand on its own.

Price the outcome, then protect the service

The service can validate whether the result matters, but don't let a custom engagement hide the actual economics. Track time spent on setup, revisions, support, and exceptions. If every customer needs a different workflow, your product may be a high-touch service with software inside—and that can still be a solid business. Be honest about what customers are buying.

For a product pilot, set a scope, a start and end date, and a price that reflects the outcome and the support you provide. Ask what would make the next month worth renewing. That answer tells you more than an enthusiastic “this is cool.” Keep some service capacity until recurring product revenue is dependable; don't quit paid work based on one good demo.

You can make the transition in stages: standardize delivery, automate one repeatable step, then offer self-serve only when the workflow is clear. The goal is a healthier business, not a SaaS badge on your website.