What is a micro-SaaS product worth?

A micro-SaaS product is a small piece of software, built and run by one person or a very small team, that customers sign up for and pay for without ever speaking to anyone. A product run by one person has no management team to buy and no sales force to inherit, so the product can be looked at less like a company and more like a cash-flowing asset. The questions to answer are what a capable operator would actually keep after every cost, including their own time, and how likely the revenue is to keep arriving once the founder steps back. This guide describes how to approach those questions in Canada. It covers method, not numbers, and it gives no multiple or price.

Earnings are recast around the hours the product still needs

The profit on the seller’s books is the starting point, not the answer. If the founder takes no salary, there is no salary to add back, and the adjustment can run the other way. One way to work is from owner earnings, the idea behind seller’s discretionary earnings, and then to ask how many hours a week the product takes to keep alive: answering support, restarting a failed job, handling a billing dispute, updating a dependency. If that adds up to a part-time job, a buyer who must put in the same hours is buying the job as much as the income. Costs need the same scrutiny. Fees charged by payment processors and app marketplaces, refunds and chargebacks, hosting that grows with usage and per-use charges from outside software services all come out of what is left, so rebuild the margin from the processor’s own payout reports instead of trusting a summary.

What the revenue is made of

Where revenue per customer is low, as it can be for a self-serve product, that cuts both ways. A base of many small accounts means no single departure changes much. A base of only a few accounts means losing one moves the whole revenue line. Ask for customer-level data and read the shape of the base: how long customers stay, how much of the revenue came from the last few months of sign-ups, and how monthly and annual plans split. Annual plans can hide churn, because a customer who has decided to leave stays on the books until the term ends, and cash collected up front for service the next owner must still deliver is not earnings. One-time purchases and lifetime deals are not recurring revenue and are best kept separate in the analysis. The entries on ARR and MRR and customer churn give the standard definitions.

Where the customers came from

How customers find the product matters as well as how many there are. Revenue that arrives through search results, directory listings or word of mouth is tied to the product. Revenue that arrives because the founder has an audience, a newsletter or a recognizable name may leave with the founder. Ask for sign-ups split by source, month by month, and for the specific pages that generate organic traffic.

Platform and account exposure

A small product can sit on a handful of platform accounts: one payment processor, one hosting provider, perhaps one marketplace listing. Each is then a single point of failure. If all revenue flows through one processor account that could be restricted, or discovery depends on one marketplace’s ranking, a decision outside the owner’s control can cut revenue overnight, which is a risk to account for in the price. The follow-up questions are practical: whose name is on each account, who holds the administrator login, and whether the account can move to a new owner at all, which each provider’s own terms decide.

What can lower the price

• Founder dependence. Support, deployments and billing fixes that only the founder knows how to do are a cost the buyer inherits. BDC lists vendor financing, an earn-out and a phased transfer of ownership as ways to remain involved, and notes that buyers may insist on a reduced price if the seller cuts all ties.
• No runbook. BDC advises documenting standard operating procedures so that operations are more easily transferred to a new owner. A product without them costs the buyer learning time and leaves risk the buyer must price.
• Unclear title to the code. The Copyright Act counts computer programs as literary works, makes the author the first owner, and gives an employer first ownership of work an employee makes in the course of employment unless there is an agreement to the contrary. No assignment is valid unless it is in writing and signed by the owner or the owner’s duly authorized agent, so code written by a contractor or an early collaborator can sit outside the seller’s title.
• A privacy posture that does not match practice. Subject to the exceptions the Act sets out, PIPEDA applies to every organization, a term the Act defines to include a person, in respect of personal information it collects, uses or discloses in the course of commercial activities. A product with no written privacy policy, or one describing data handling the software does not follow, is a gap for the seller to fix and for the buyer to raise and weigh.
• An unrecorded incident. PIPEDA requires an organization to keep and maintain a record of every breach of security safeguards involving personal information under its control, and to give the Privacy Commissioner access to it on request. A missing or empty record next to a known incident is a question for the buyer to put to the seller and to their own lawyer.

How two products with the same revenue can differ

Take two products that bring in the same monthly revenue from a similar number of customers. The first finds its customers through search traffic, bills through a processor account held by the company, keeps a written runbook and takes the founder a few hours a week. The second grew out of the founder’s newsletter, bills through an account in the founder’s personal name and runs on knowledge that lives only in the founder’s head. The first is easier to hand over, and the second leaves a buyer more to fix or to account for in the price. Which differences matter most also depends on the buyer’s own plans: someone who would run one product alongside other commitments should test the weekly hours closely, and a small company assembling a portfolio should test how easily the product can be run without its founder. The answer on what multiple a SaaS business sells for puts the general market discussion in context.