You get hit by a car! What then?
Today I met with a potential client to talk about a partnership regarding my SaaS app to provide my service to his customers.
He asked me the following question:
"Since your running that business alone, what happens in case you're no longer able to work on that service (maybe because of a car accident)?"
What would you respond?
Good question!
This is something that's more commonly known as the 'bus test'.
The first thing is, obviously, to always respond honestly.
My initial reaction would be to work out what exactly the potential client is worried about. Is your SaaS mission critical for that client? Are there potential competitors to be switched to? How much work does the client have to invest in integrating your SaaS into their company/product?
I then ask the client how they mitigate this risk for their own employees. There are probably much more risky 'bus test' scenarios within the client's company than you represent, so this helps relativise the risk in the eyes of the client.
Your response/planning then needs to be proportionate to the risk for your clients.
Perhaps you are working with another developer who can take over and keep things ticking over for a week/month/year/indefinitely in case something happens to you?
Perhaps a guarantee that it's always possible to export all data would suffice.
If you're really small, perhaps you have an agreement with a competitor who has agreed to grandfather in your clients at their current prices? (less common)
Hope that helps!
Hey Louis,
I like your answer very much! Didn't know the term bus test, so this article you linked up was a good read!
My reaction to my customer's questions was indeed totally honest, and I told him that I haven't thought about that topic ever at all.
We then just discussed together about ways to mitigate the risk for them, and this is what we came up with:
This comment was deleted 7 years ago
This isn't such an unusual question, see the wikipedia page on "Bus Factor" - https://en.wikipedia.org/wiki/Bus_factor
On a team of one it's quite difficult to mitigate as you need at least one other person who would be willing to step in and help you out, and you need adequate documentation for them to understand it.
I've seen this scenario to "solve" the problem: The solo-founder has a contractor familiar enough with the business and willing to step in on his death and take over the business. If the founder dies, a life-insurance policy that the business owns buys the company for the contractor from the founder's estate/heirs. So the outcome of his death is that the business is sold to the contractor, the contractor keeps it going and the founder's heirs receive cash.
I like the life insurance idea. Very good!
I've had this question multiple times in my career. Some clients have switched to a larger company, and a single developer in that company takes the reins. For smaller projects, it's often one developer that is deeply familiar with the code base. And in a company, that developer/employee can and does quit. It can be quite expensive to introduce a new developer to a large and complex codebase cold.
I've offered to bring a backup developer into a project, and the company refused to pay. Now my main go-to in case of an issue doesn't want to have anything to do with this company. So before you burn a colleague trying this out, make sure the company is willing to pay for this assurance. Again, it is expensive/ time-consuming to introduce a new developer to a project, even if you are there to explain the codebase.
It can be awkward to sit at a table with a client and discuss how they should handle your death. In every discussion I've had, the client assumes a defensive posture and can sound angry, angry at you for imagining that you have died and completely screwed their business up. The life insurance idea is the first I've come across that could preempt the difficulty of this discussion.
At least with a solo-founder, it is almost certainly the case that they are passionate about and dedicated to their product. A client probably won't get that level of commitment from an employee at a company. All of the apps that have replaced mine when a client went with a larger company to insure themselves against the bus factor don't have the same level of quality. In one case, I suspect the company needed to hire several more employees because of the degree of automation they gave up - and may have damaged their business in the process.
I've been brainstorming doing business-ops-as-a-service for a flat rate. Sort of like an agency retainer or Design Pickle model. Anyone interested? I should throw up a landing page and collect emails.
What about an agency that could receive a wiki of information and system passwords via a dead man's switch. Then they would engage when required to use that information and, to their best ability, help keep servers online, help customers extricate their data, help find new operators to run their business, etc.
Call it Fallback. Small-time operators could have a "Protected by Fallback" pledge/badge in their site footer.
I was once a lone wolf working on a web platform for one of Australia's larger companies. Flew interstate to meet at their head office. Met in a boardroom where they asked me, "So, what would happen to our site and system if you were hit by a low flying pelican?" I had no confidence-inspiring answer for that!
That's a really good idea.
lowflyingpelican.com is available too.
This is one reason co-founders are so popular./demanded by employees. There is someone to step in if needed.
This is where it pays to have a real team and real business processes. Unfortunately his concerns are very valid.
One way this is handled is with source code escrow handled by companies like iron mountain. Though I'd say that's for more higher value deals than you are likely chasing after at the moment. Basically if you go out of business they get the source code type thing. All sorts of caveats with that though.