A Failed SaaS Postmortem

An interesting write-up Matt, thank you for that. It validated some of my own observations of how businesses are actually built and although it didn't even get off the landing ground, it was nice to read even as a technical report of what not to do.

While I do not have experience of running my own start-up, I have with keen interest seen people build start-ups around me and by far the biggest leading factor to their success is the team. The team is everything. Sure, you can maybe sketch up a decent app and maybe sell it to couple businesses but then what? You'll be over your head with work and maybe hire some of your friends and if things work out well, it could work. But why didn't you hire those great friends then in the beginning? Why didn't you cofound the company together?

See there's something about people working cohesively in groups that just outmatches anything that a 1-man team could do. Now I'm generalizing here a little, but the fact of the matter is that alone, without your peers to constantly revalidate, build and improve your business-idea, you'll be miles away from those teams that are actually doing it. And if the idea sucks, you'll just pick another one. It's just that easy. When you have a group of friends who are that driven and capable as you are, it's only matter of time when your start-up actually takes off. There are so many would I say "mediocre" folks running perfectly good companies because they had great co-founders, had those social skills and networks to grow larger and eventually it became self-sustaining.

Hmm it's still a bit hard to pinpoint the exact reason why I think it is so. Maybe if I put it in this way: you are creating a machine made of humans. In the heart of it is the dynamo, the moving force. That is what keeps it moving. And even if it would one day be gone for some reason the machine will keep running, by its inertia, for who knows how long. But to build this starting unit, this dynamo. It is what starts this whole process.

In this case, sure you made the wrong calls with your tech choices. Understandable. But if you had a good co-founder, or even better a good team, I'm sure you'd have together figured out in no time that this was a dumb way of doing this, and picked up something you knew and were able to execute with quickly. It could have been just jQuery and PHP5 and be just as fine as any new framework (with a massive technical debt waiting, sure) but that alone would have not killed your start-up.

I had a good experience doing many of the things the author suggests doing but maybe didn't also as an evening / weekend fun project.

I built an app for a business. It was a very simple app - one or two input choices / data but a somewhat complicated process from there (2-3 minute runtime). High business value in the sense that it saved about 15 minutes of staff time per invocation with hundreds of invokes.

But I didn't know how to build UI front end or do authentication. So I built the app without any of that, you passed the data in at the command line, then it emitted data out.

Great - I would run the app for folks based on the data they sent me by slack.

That worked great - happy users who gave me immediate feedback on the results of the app, I was literally in the run cycle.

Then I discovered slack had a webhook/websocket system - instead of sending me the data by slack, they could send the data to my app using slack. Perfect, no front end needed AT ALL, AND authentication as already handled - all the slack users in the company should have access. So slack called the CLI, then sent back the result.

User count went up, and I deployed to AWS by just doing a git co on the server by hand, picking up requirements.txt, then manually fixing the enviro issues (even with a virtenv) by hand directly on the server and doing a snapshot of the machine.

Very happy users - usage goes up.

More change requests, and deployment approach not great.

Finally I stuck a docker file on my machine because I HAD to, then set up the CLI based deploy into fargate on AWS, which worked great for me - I would develop, test on my machine, then run the three commands AWS gives to push my docker into fargate. This still worked well.

THEN one of the integration partners changed, so I had to update things on my setup, and discovered the Slack toolkit had changed and the recommendation was to upgrade, which I did, which started an upgrade cascade. In my busy time working nights and weekends - boom - the app was dead!

It was so boring not adding new features and making folks happy, but instead redoing things to the "new better way" which made absolutely no difference to anything I cared about. And every time I messed with one thing another thing needed changing.

So I totally get that trying to keep an app up to date with libraries etc might kill your productivity. It killed mine, and I waited as long as I could.

Hey, I can relate to this! I also started a company based on a specific pain point in my spouse's profession. Although the best situation is to solve a problem you've experienced firsthand, having a significant other be able to give honest feedback on a specific challenge is pretty great.

I think the tough part that engineers have with these types of side projects is that it's hard to assess how much time to devote to developing the product. A lot of people will try to convince you to spend all your time talking to the customer. I mean that's important too, but it's so much easier when you can show them something that's great rather than just tell them about it. And that's the thing - product development isn't most important thing to do in the early stages, but it's still very important.

I wish there was more insight into why the project failed though. It wasn't clear to me the project had to die. If he started focusing on customer development, could the project have survived? Could he win back his wife's interest? I was a tiny bit disappointed because his project is an adjacent area to one of my company's products and I want to see it succeed!

I love the discussion about all this. For a bit of context, I kept the article focused on the technical because that is the primary audience of my website. There is a criticism that I focused too much on the technical side in the article. That's entirely possible.

My choice to focus on the technical is because my lessons basically boiled down to:

1. Don't focus on the technical (#1 YAGNI, #2 Ignore software upgrades, and #3 use the tools you know)

2. Deliver something valuable to the customers as fast as possible.

In other words, I tried to say "don't focus on the technical side."

I admit in the article that the technical focus of the article itself was emblematic of why the project failed.

Up to this point, I’ve written about the technical failings of the project. This is an emblematic example of why the project failed. I didn’t help my customers and was too focused on the technology.

Perhaps I was too subtle on that point.

Thanks for all the feedback. I've enjoyed reading the discussion.

I don't understand what the web world considers to be rapid technology change. All of the products and frameworks that these developers are using feel like a marginally better side step from the bare bones approach for small ventures. I understand if you are a giant tech company why you might adopt one of these technologies, but I have no idea why the common developers would be interested in expanding their knowledge in this direction.

I would rather go in depth, strengthen your core, learn about different paradigms, algorithms and structures. Why are you going into frameworks and technologies that your employer is not forcing you to adopt? It is an incredible effort to understand a technology and its specifics. What is the value in this, it will be obsolete in a few years at best and odds are that you will never use it again.

If large portion of your knowledge is frequently invalidated, how do you people not burn out 5 years into your careers?