A 7-year SaaS listed for sale because of a server migration

Even a SaaS with revenue becomes hard to continue if one person can no longer carry a platform migration and the day-to-day operation. One listing I saw on an M&A site reported 47 paying companies and positive year-over-year revenue, and gave insufficient operating capacity and the response to a server migration as the reasons for the sale.

This is not a statistic that “the cause of death of an indie SaaS is technical debt.” It is the seller’s explanation of one listing. Public information also cannot confirm whether it eventually sold, or whether the migration was the only reason.

It is still a concrete example of the risk you miss if revenue is the only condition for continuing. This article turns that into a way to check, on my own SaaS, the end date of an external platform, operations that only a specific person can touch, and the work a handover requires.

I am building Shoryaku AI ( https://shoryaku.net ), a marketing-support SaaS, as an indie developer.

Scope of the listing

The subject is a booking and customer-acquisition management system, of the type that connects with LINE official accounts, that was listed on ラッコM&A. Every figure is the seller’s own statement.

The article at the time of publication wrote the asking price as a “sale price.” The correct label is the asking price at the time of listing. The closed amount, and whether it closed, cannot be confirmed.

What was written as the reason for the sale was insufficient operating capacity, and the difficulty of handling a migration that comes with the end of support for the server in use. This too is treated as the seller’s explanation, not as a cause a third party verified.

The problem of having called M&A listing information as a whole “actual sales,” and the correction of the multiples, is summarized in An indie SaaS sale price cannot be known from the asking price alone.

What this one listing can say, and what it cannot

In particular, even if you replace ARPU with another price and calculate “with the same customer count, how many times the revenue would be,” the conversion rate, the churn, and the support load are not necessarily the same. I removed the simple price comparison that had been written at the time of publication.

Five items to check on my own SaaS

1. Deadlines on external platforms

For each of the runtime, the database, authentication, payments, and ad APIs, list the support end date and the update frequency. If a deadline has not been announced, keep the current version and the date of the last check.

2. The time a migration takes

Not “move it someday.” Raise it to a new version in a development environment, and record how many hours the tests, the data migration, and the rollback take. A state in which it cannot be estimated is itself a risk.

3. Work only the operator knows

Check whether incident response, billing checks, API re-authentication, and customer support can be carried out by someone else from a procedure document alone. For work done by hand every month, also keep the frequency and the time it takes.

4. Conditions for stopping an old dependency

Even a feature with few users leaves update work as long as an external API or an old library is maintained. Look at the usage count, the contribution to revenue, and the alternatives, and also decide the conditions for ending the feature instead of migrating it.

5. Evidence a handover needs

Keep the deploy steps, the list of environment variables, backup and restore, monitoring, costs, and external contracts outside the code. Before whether a buyer wants them, they are needed so that your future self can keep operating.

What I reflected on our side

Shoryaku AI runs on Firestore, Cloud Functions, Firebase Hosting, and several external APIs. After seeing this case, I added the following to the checks for choosing the stack, in addition to “whether the fixed cost is low.”

• Whether a runtime update can be checked with automated tests
• Whether indexes, Functions, and Hosting can be reproduced with the same procedure
• Whether external API versions and re-authentication conditions are recorded
• Whether there is a deploy and incident-response procedure that someone other than me can read
• Whether the time that can be used for a migration is included in the operating effort of the business

Whether this check can prevent a future sale or shutdown is unverified. What I have at this point is a criterion: check the trend of revenue, and the state in which operation can continue, separately.

Summary

• A SaaS that reported 47 paying companies and positive year-over-year revenue was listed for sale, with insufficient operation and a server migration as the reasons
• It is one seller’s statement. It is not data for generalizing “the cause of death of indie SaaS”
• ¥2,500,000 is an asking price, not a closed amount
• Separately from revenue, check platform deadlines, migration time, work that depends on one person, conditions for ending a feature, and the handover procedure
• For a judgment about long-term operation, hold revenue and the ability to keep operating as separate indicators

• SaaS
• M&A
• Indie development