How to build a SaaS without selling custom projects

How to build a SaaS that does not become a custom project

To build a SaaS, turn a recurring customer job into a service that different customers can use through the same core product. Before commissioning development, define the promised outcome, the setup work, the limits of customization, and the cost of keeping each account operational.

The decisive question is not just whether someone can build the software. It is whether the next customer can receive value without requiring a different solution, process, and delivery team.

This guide focuses on that commercial and operational boundary. It helps you decide what to standardize, what to sell as a service, and what evidence to request before increasing your investment.

SaaS, recurring services, and projects are different things

SaaS is software delivered as a service, typically through ongoing access and subscription or usage-based billing. A subscription alone, however, does not establish a repeatable product.

A custom project can be billed monthly. A SaaS product can include implementation consulting. The distinction is what must change to serve each buyer.

Use three definitions in your SaaS planning:

• Shared core: the workflow supported customers use, even when their settings differ.
• Implementation: the work required to make an account ready for use.
• Additional service: human assistance purchased separately for a particular need.

These categories are not a ranking of business quality. A service business may be the right choice. Trouble starts when pricing and promises assume a product, while delivery depends on unbudgeted specialist work.

Map four stages before writing the feature list

We propose this map as an editorial decision guide; it is not an official method from the sources cited. SaaS means software as a service; an MVP is the first usable version designed to test an assumption.

Describe the journey from the customer's job to renewal. For each stage, record an assumption, an owner, and something you can observe to test that assumption.

1. Job: choose a unit of value

Define what the customer needs to accomplish and under what circumstances. Avoid broad promises such as better management. Choose a task with a recognizable beginning and end.

Identify who performs the work, who approves it, and who pays. These may be different people with different expectations.

Then define the boundary: which adjacent jobs will the offer not support? Without an explicit boundary, sales conversations can quietly expand the product.

Useful evidence includes observing the current workflow, documents, and exceptions with permission. Interest in a demonstration does not establish that different buyers share the same process.

2. Setup: make implementation work visible

List everything required before meaningful use: preparing data, setting permissions, importing records, training people, and checking outputs.

Classify each activity as standard configuration, optional assistance, or custom development. This makes the commercial proposal more transparent.

Assisted onboarding does not disqualify a SaaS business. The risk is needing an expert to rebuild the customer's process after every sale without reflecting that effort in the price or schedule.

Observe which activities require specialist judgment and which can follow instructions. Do not automate immediately. First establish whether the same sequence actually repeats across accounts.

3. Value: verify that the job gets completed

Registration and login are not the primary outcome. Choose an event that indicates completion of the promised job.

Record the assistance required, too. A task completed by the supplier's team means something different from one completed by the intended user.

For a SaaS MVP, preserve one narrow but complete path: input, execution, output, and handling of foreseeable failures. Secondary features can wait; an essential step cannot simply vanish.

Manual work can support learning when it is visible. Otherwise, you may mistake operational effort for product capability and commission automation before understanding the process.

4. Renewal: connect continued value to billing

Explain why someone would keep paying after the first successful use. Continuing value might come from repeating the task, coordinating people, or maintaining an active process.

Choose a billing unit that reflects this logic. Accounts, operating locations, users, and consumption are alternatives, not universal recommendations.

Include cancellation, data export, failed payments, and support in the offer. These situations are part of the service even when they are absent from the demo.

Treat renewal as a separate assumption. Successful one-time use does not establish an ongoing need.

Choose a delivery route, not just a technology

How you build should follow the intended service rather than your initial technical preference.

| Route | When to consider it | What to examine | |---|---|---| | Configure an existing tool | Available products already support the workflow | Licensing, resale rights, export, and adaptation limits | | Use no-code or low-code | The workflow fits the platform's components | Permissions, integrations, usage limits, and platform dependency | | Commission custom development | Important requirements are poorly served by alternatives | Maintenance, security, testing, and operational ownership | | Deliver an assisted service first | The process still changes during delivery | Visibility of manual work and conditions for standardization |

None is automatically cheaper over its full life. Compare the cost of launching, changing, supporting, and eventually migrating the service.

Give prospective vendors the same reference workflow and exceptions. Otherwise, apparently comparable estimates may describe very different deliverables.

Fictional example: a subscription with bounded setup

The following scenario was invented from scratch for illustration. It is not a Soulsy customer, project, or reported result.

An operations coordinator for shared creative workshop spaces imagines software to organize material loans. The initial business model assumes a subscription for each active location.

The proposed core records requests, checkouts, and returns. In the fictional purchasing discussions, some buyers want the provider to organize their entire inventory. Others request unique approval rules.

The coordinator separates these requests. Importing records through a defined template belongs to implementation. Physically organizing inventory becomes an additional service. Rules requiring account-specific programming remain outside the initial offer.

The pilot would observe whether users can open and close a loan, what assistance they need, and whether common settings support their workflow.

This does not demonstrate success in advance. If every location still requires a different operation, the next decision might be to narrow the audience, change the offer, or deliberately run a service business. Each is clearer than hiding custom work inside a subscription.

Calculate delivery costs, not just hosting

A useful starting calculation is:

Account contribution = account revenue − costs directly attributable to serving that account.

Depending on the business, those costs may include variable infrastructure, third-party services, payment processing, and support or operational labor.

This contribution is not profit. Development, sales, administration, and other shared expenses may still need to be covered.

Evaluate implementation separately. Compare any setup revenue with the work required to get the customer operational. If you subsidize onboarding, make that an explicit financial assumption rather than an invisible concession.

During a pilot, record time by activity. The purpose is not to manufacture a precise margin from limited information. It is to discover where each additional account creates more work.

Common mistakes that blur product and service

• Accepting every exception to close a sale: the contract starts defining the product without an assessment of consequences.
• Charging per seat out of habit: pricing may align with neither customer value nor delivery costs.
• Automating an unstable process: changes in understanding become technical rework.
• Treating security as finishing work: access, data handling, and incident response need owners during planning.
• Measuring registrations alone: signups reveal little about task completion, support dependency, or continued use.

An exception does not have to be forbidden. It needs a deliberate decision about scope, price, and maintenance responsibility.

An action plan before you commission development

Prepare a short brief describing the main job, buyer, shared core, and exclusions. Map implementation and assign responsibility for each activity.

Next, choose the task you will test from beginning to end. Specify which observations would justify continuing, revising, or stopping the investment. Avoid importing arbitrary targets from unrelated businesses.

Use the brief to compare platforms and development partners. Ask them to state assumptions, dependencies, post-launch responsibilities, and exit conditions.

Your first commissioned deliverable should reduce an identified uncertainty, not merely produce screens. A polished interface cannot resolve an undefined delivery model.

Sources and limits of the evidence

This is a decision framework, not a promise of results. These sources support specific practices:

• NIST SP 800-218, Secure Software Development Framework: organizes secure development practices across the software lifecycle. It does not certify a product or establish commercial viability.
• Stripe, Subscriptions overview: documents subscription lifecycles and billing events. It supports operational planning, not a universal pricing recommendation.
• GOV.UK Service Manual, Measuring success: provides guidance on defining and monitoring service performance. It does not supply benchmarks for this particular SaaS.

FAQ

Do I need to code to build a SaaS?

Not necessarily. An existing tool or no-code platform may support the intended workflow. Evaluate permissions, export, integrations, and operating costs before choosing. Avoiding custom code does not remove your responsibility for running the service or handling customer data appropriately.

How do I validate a SaaS idea beyond positive feedback?

Combine observation of real work with commitments appropriate to the stage, such as making time for a test or evaluating a concrete proposal. Record who used the service, what they completed, and how much assistance they needed. Compliments alone do not demonstrate recurring adoption.

Can a SaaS MVP include manual operations?

Yes, when the work is visible and answers a learning question. Record what the team does, why it does it, and whether the activity could become standardized. Do not present a manually delivered outcome as an already automated product capability.

When is custom development worth considering?

Consider it when there is a concrete reason existing alternatives cannot meet important requirements, alongside the capacity to fund maintenance and operations. Visual differentiation or a preference for a particular technology is a weak standalone justification for taking on that responsibility.

Conclusion

Building a SaaS means defining a service that can be delivered repeatedly, not merely putting software online. Clear boundaries between product, implementation, and additional services make scope, pricing, and investment decisions easier to examine.

If you understand the problem but still need to organize these decisions, the Soulsy diagnostic offers a next step for structuring the conversation before commissioning the build.