Live data from Hacker News

A Failed SaaS Postmortem

mattlayman.com

51–60 of 141 posts

Re: A Failed SaaS Postmortem

#51

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…

It's a constant treadmill.

Developers see people switching jobs a lot. They read Hacker News and blogs and read about new frameworks. Companies are afraid all their people leave and they can't find replacements. Developers are afraid their skills will go out of date and they will be left behind when everybody is on Shiny Thing 2020 and they have never used it. Developers jump for jobs that promise them they can work with Shiny Thing 2020. Companies feel forced to rewrite things that are a few years old in it because their remaining developers are clamouring for it and they can't get new people in to work with tech from 2017. Repeat ad infinitum.

I was out of web dev for a while in research, where we wrote code for machines in C. Libraries were ten years old and worked fine. It was boring as anything. I accepted that I'm addicted to the treadmill and went back to the web.

And finally there is the promise of the pot of gold at the end of the rainbow: obviously the way we do Web development now is insane, but one day we will figure out how to do it right. And it will be beautiful, clean, extremely quick to develop, every application will be a web app and it will ultimately be boring.

I hope it happens the day I retire.

Also Django and Typescript are genuinely good tech and React is a clear small step towards the pot of gold.

Re: A Failed SaaS Postmortem

#53

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…

Wish I could upvote this twice. Roughly speaking, "building the product" is maybe 20-30% of the actual business. The other 70-80% is what makes or breaks an actual company - market research, customer discussion, sales, marketing, support, accounting/finance, etc.

Re: A Failed SaaS Postmortem

#54
I'll go out and say it. Most Indie SaaS developers don't really really want to start a business.

They might want it consciously and convince themselves of this fact, but sub consciously they are making the wrong choices, optimizing the wrong things, digging their own grave.

The moment things like customers, prices, marketing, money, taxes, lawyers, incorporation, accountants, employees — all SUPER normal things in any business — come around they freeze up. Safer to upgrade Bootstrap.

Re: A Failed SaaS Postmortem

#55
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.

Avoid adding tons of tiny JS deps that require maintenance= move faster

Avoid adding jQuery & write your own slideUp, slideDown etc. = move slower

Re: A Failed SaaS Postmortem

#56
"At the start of the effort, I asked my wife questions about what she needed and what would help her and other educational consultants like her. She told me the things that she was looking for directly. But it took forever to have something tangible to show her."

It's more efficient to get feedback on a few UI mockups than building a fully functioning application. And if you get a positive response, it stokes enthusiasm and momentum.

Re: A Failed SaaS Postmortem

#57
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…

Nobody's as smart as they think they are. Even if this guy was an EXPERT, as a one-man shop, he can't be an expert in everything, and "hired gun" coders can still out-code him across all disciplines in aggregate, even if he's better than any one of them in a specific discipline/component.

Re: A Failed SaaS Postmortem

#58
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 must have a small development team that turns over infrequently. The purpose of cultivating development ecosystems is to attract developers, and quickly. We migrated to Angular 6 and were able to hire 5 front end developers and get them productive in 2 months.

You're not wrong about the size of the dev team and turnover.

At the same time, I'm not sure if taking 2 months to get productive is a win? Wasn't one of the angular "upgrades" a total rewrite? What is the overhead of maintaining a second tightly coupled front-end app. I found doubling the surface area seemed to square the effort, not double it. How much of that productivity is illusory and could be done with fewer people?

Some folks are upvoting the heck out of my comment. I presume some portion of those are devs who might like working in a place without JS dependency package/upgrade/language/promise hell?

Re: A Failed SaaS Postmortem

#59
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.

> native JS works just fine for most simple interactions like startup apps

Oh god please don't. I worked with a startup whose "lead" (i.e. the person with the most seniority, not the smartest) insisted the whole front-end could be done with plain JS ("angular, jquery, etc... just useless bloat!!!" said the lead developer). What resulted was the biggest rats-nest soup of untraceable mess I've seen in a while. The only person on the team who understood the system was the "lead" developer. Changes took forever. Bug count was through the roof.

When you say "you don't need a framework", what you are really saying is "I'll build my own framework". Because you will be building a framework. And trust me, your framework will not be as good as what is on the market. And when you leave, all developers who didn't leave the company will rip all your shit out and replace it with a "real" framework -- all while cursing your name under their breath.

Your job at a startup is to get product-market fit. Not invent your own framework.

Re: A Failed SaaS Postmortem

#60
post #14

Earlier quoted context omitted.

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.

Can you name, say, three notable software businesses whose advantage was hard-to-replicate tech?
Post reply on HN