Live data from Hacker News

A Failed SaaS Postmortem

mattlayman.com

31–40 of 141 posts

Re: A Failed SaaS Postmortem

#31
post #7

The 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…

Solutions come from hard work, perseverance, and listening to customers over years of work.

They almost never arrive fully formed and then take the market by storm, on the contrary most overnight successes have years of grinding away on a project behind them, not years of building, but years of tweaking, listening and going back to the drawing board.

The technology used doesn't really matter much, just use what you're comfortable with, because it's about 10% of the problem. The rest is hard work that can't be replicated overnight.

Re: A Failed SaaS Postmortem

#32
post #18
post #7

Earlier quoted context omitted.

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…

Never, ever, ever, ever worry about anyone copying your stuff. Depend on your unique insight. No one can copy that. If in the extremely rare circumstance that someone copies you, be thrilled! That means you are building something valuable (which is extremely rare).

The only time someone will NOT copy you, is if the market is not worth it. But this is by definition a market that you should not play in.

Look at markets that are worth it (e.g. cloud computing)- they have products from different companies with exactly the same features.

In general, I am not sure what you are proposing. Let me publish my ideas for free, see someone copies them, and that be happy that I got it right?

Re: A Failed SaaS Postmortem

#33
post #13

Earlier quoted context omitted.

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.

>User Experience. Developer Experience. Community. But that's what I'm saying. If you find some solution to a problem that's making decent money, some guy with big capital will just come in and "fast follow" you with better user experience and advertise the shit out of it until they have a better or at least more active community. Like suppose this guy's admissions scheduling app actually started making money. Why wo…

While Pearson have the advantage of some connections at universities and in the education sector, they also have the disadvantage of being a large and slow organization. Hiring 25 people won’t get you a better product than that lone wolf has, unless you (the one hiring the 25 people) have the vision and understanding of what those 25 people are going to build.

And from what I’ve seen of Pearson, I highly doubt they have a clue. Their existing business survives due to market inertia, but they’re very far from delivering quality products.

Re: A Failed SaaS Postmortem

#34

The 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…

Yes. The other way to look at it is that #4 on his list is the only learning that truly mattered.

>>Get your product to be something useful for others as fast as possible. Until you deliver something valuable, you only have a hobby.

The other learnings are simply things that shouldn't be done at the expense of customer development.

Re: A Failed SaaS Postmortem

#35
post #14
post #7

Earlier quoted context omitted.

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…

hard to develop technology is a very narrow moat. You have the first problem that well-funded competitors can almost certainly replicate whatever you built if they care to do so. You then have a second problem that well-funded competitors can almost certainly market inferior tech as being equal to or superior to yours, if they care to do so.

Hard to develop tech is a huge moat. The issue here is timing. Hard tech buys you time. Most of the M&A today is not done due to hard to replicate, but due to time. Even if I can replicate the tech, I do not have time to do that.

Re: A Failed SaaS Postmortem

#36

I 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 patc…

unless you find yourself with an overwhelming number of customers all at once (which would be a nice problem to have), and that upgrade is what would have prevented a problem, trying to keep up-to-date before building the actual product just busy-work.

Re: A Failed SaaS Postmortem

#38
This is not a postmortem of a failed startup, maybe a failed app.

The fact still is that to your consumer the software makes 0 difference. They will never know if you're running php or python, serverless or cloud.

It's all a moot point until you hit at least $10k mrr or something. If you are spending majority of your time on these technologies then who is working on getting the leads, sales, seo, and the other little million things that are equally important for success, if not more.

Re: A Failed SaaS Postmortem

#39
post #8

We 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 don’t need jquery either, native JS works just fine for most simple interactions like startup apps. Time to say no to npm and packages like is_odd that somehow are depended on by thousands of packages. A sign of collective hysteria.

Equating jQuery and is_odd feels extremely disingenuous to me, and gives the argument a purely-dogmatic feel.

Re: A Failed SaaS Postmortem

#40
It’s very hard to manage your time as a nights and weekends project. You should consider it a skill of equal importance as coding/design/marketing.

I’ve written about it here: https://blog.cronitor.io/the-jit-startup-bb1a13381b0

The main takeaway:

"If you’re a software developer it’s especially tempting to justify spending more time on your software. You’ve worked with tangled messes of code in the past and suffered through others’ poor product choices. This is your chance to “do it right” from the beginning, but that’s a trap! Never write a line of code today that can be put off until tomorrow. Focus exclusively on the essentials, and handle everything else over a support channel."

Post reply on HN