A Failed SaaS Postmortem
mattlayman.com
A Failed SaaS Postmortem
1–10 of 141 posts
Re: A Failed SaaS Postmortem
#2The main point here seems to be that the failure to build a SaaS product is blamed in part on the compounding technical debt incurred due to a fast-moving software ecosystem and the effort involved in keeping up.
The point I think most people should consider instead, is that building an app is not the same thing as building a business. Building the app is comparably easy, once you've proven that you understand the market, your target buyer, and have a unique insight/tool/solution to offer that you can deliver via software.
If you want to learn a technology, by all means build an app. But if you want to build a SaaS business, keep focused on building the _business_. The app, it turns out, is the easy part.
Re: A Failed SaaS Postmortem
#3> I didn’t help my customers and was too focused on the technology.
Great write up, though this gold nugget should be in a massive at the top instead of at the bottom underneath a whole lot of coding talk.
The more I interact and learn from businesses the more I'm convinced founders need to categorically stop writing code, buff up soft skills, and tirelessly hammer the business needs at near complete expense to software development. Yes some companies really are engineering first and need an engineer at the top, but most don't.
Re: A Failed SaaS Postmortem
#4> I didn’t help my customers and was too focused on the technology.
Somewhat ironic that your Postmortem is highly focused on technology as well :)
But seriously, SaaS businesses are still businesses. I think so many software developers think “I can build that!” about X and fail to realize how much of a business has nothing to do with the product.
Re: A Failed SaaS Postmortem
#5I think many people's corporate jobs don't prepare them well for the world of startups. You tend to focus on optimizing some subset of a feature/product etc. With a startup you need a much broader skillset and need to ship quickly. So you need to master some subset of tools to be full stack and be able to launch something in 2-4 weeks. Taking more time than that and you're just setting yourself up for failure. The hard part is the feedback cycles on the product, the marketing etc. So you obviously can't spend 2 years on what is (or at least should be) the easy part of your business.
Re: A Failed SaaS Postmortem
#6I disagree regarding software upgrades.
On the one hand, it is true that unless you have customers, what you have is just a hobby, and you should refrain from stuff that distracts you from solving the core business problem.
On the other hand, certain things become a lot harder and a lot more complicated once you have users, because the stakes are higher. So there is value in making sure you're fully upgraded and patched up before you cross the Rubicon, so to speak.
Re: A Failed SaaS Postmortem
#7The main point here seems to be that the failure to build a SaaS product is blamed in part on the compounding technical debt incurred due to a fast-moving software ecosystem and the effort involved in keeping up. The point I think most people should consider instead, is that building an app is not the same thing as building a business. Building the app is comparably easy, once you've proven that you understand the ma…
The only problem with not caring about the technology, is if your solution is trivial to replicate then anyone with a bunch of cash can come in with hired gun coders and out advertise you. Hard to replicate technology gives you some kind of a moat to at least slow down copy cats.
edit: Oh, I see, the guy in the article was just throwing together random open source stuff not actually developing anything of value. Never mind.
Re: A Failed SaaS Postmortem
#8We just did something crazy. We dropped the Ember app that was 3/4th's done in favor of plain JQuery and Rails 6.
I'm just done maintaining two apps instead of one and all the hell that involves. And the Javascript ecosystem can keep rolling that Sisyphean upgrade treadmill with deploy dependencies and promises everywhere and I promise to use it as little as possible. Because it is just a giant time suck. Tut tut if you will, but we are moving twice as fast now.
No one sings of your glorious battles maintaining JS apps in the halls of Valhalla.
Re: A Failed SaaS Postmortem
#9> I didn’t help my customers and was too focused on the technology. Somewhat ironic that your Postmortem is highly focused on technology as well :) But seriously, SaaS businesses are still businesses. I think so many software developers think “I can build that!” about X and fail to realize how much of a business has nothing to do with the product.
Given how often it is said that "build it and they will come" is an untrue trope, you would expect people instinctively know to avoid spending too much time on the build it part. I however am guilty of this myself so I can't really blame the author and think most just tend to get lost in the implementation phase because it's far too comfortable.
Re: A Failed SaaS Postmortem
#10The main point here seems to be that the failure to build a SaaS product is blamed in part on the compounding technical debt incurred due to a fast-moving software ecosystem and the effort involved in keeping up. The point I think most people should consider instead, is that building an app is not the same thing as building a business. Building the app is comparably easy, once you've proven that you understand the ma…
The only problem with not caring about the technology, is if your solution is trivial to replicate then anyone with a bunch of cash can come in with hired gun coders and out advertise you. Hard to replicate technology gives you some kind of a moat to at least slow down copy cats. edit: Oh, I see, the guy in the article was just throwing together random open source stuff not actually developing anything of value. Neve…
I'm not sure "hard to replicate technology" is a moat I'd often bet on, given that by definition that does not deliver any specific advantage to your customer.
User Experience. Developer Experience. Community. Those are moats you can bet on primarily because it takes so much dedication, expertise, and work. That's not easy to buy.