Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Failed SaaS Postmortem

mattlayman.com

Post reply on HN
Print view View original

41–50 of 141 posts

Re: A Failed SaaS Postmortem

#41

Post by x0x0 »

irq11 wrote: post #24
tunesmith wrote: post #22

So many big frameworks are oriented towards big companies and many hands, and I understand why, but I wonder if there are examples of frameworks that are designed for single authors, that are designed to stay simple and change slowly, like an LTS release. Like, I still know how to write html hooked to php scripts, but once you want a javascript event model it seems like React swallows everything.

Rails works really well for single engineer projects. It’s just not the hotness of the moment. It’s pretty cringeworthy to see someone parroting the “use boring technology” line, then immediately running off and making an SPA for something that...let’s be real...could probably be done in a week or two by a single developer with a Rails install and little else.

another vote for rails, bootstrap, and a sprinkling of jquery.

Re: A Failed SaaS Postmortem

#42

Post by pbreit »

streetcat1 wrote: post #32
pbreit wrote: post #18

Earlier quoted context omitted.

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?

Thought it was clear: "Never, ever, ever, ever worry about anyone copying your stuff."

Re: A Failed SaaS Postmortem

#43

Post by jahbrewski »

Eikon wrote: post #29
jahbrewski wrote: post #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.

I wouldn't say building a business has nothing to do with the product. The issue is when the focus is _only_ on the product and no effort is done on business development, market research, marketing... Garbage is an harder sell than outstanding especially with limited resources. However, if "outstanding" means "I think they'll throw money at it, I just have to wait", you've got a problem.

In no way am I saying the business has _nothing_ to do with the product. Simply that it’s probably far less than the developer in many of us wants to accept.

Re: A Failed SaaS Postmortem

#44

Post by hinkley »

throwno wrote: post #7
briandoll wrote: post #2

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…

There was a podcast I listened to years ago that stuck with me. Every time it comes up I vow to find a link but never get around to it.

The guest proposed a model of software features and why “agile” fails for a lot of people. On a two dimensional graph of difficulty and profitability, everyone avoids the high effort, low value quadrant. That’s a no brainer.

Problem is a lot of policy ends up avoiding the high-effort column entirely.

Low-effort features are only short term differentiators, if even that. They offer no long term viability.

To have features your competitors don’t have is going to take real work.

The only loophole I know for this is if my code quality is good, what is a moderate effort feature for me may be a high effort feature for you. If my pockets are deep I can just run my competitor down, by setting an agenda they can’t afford.

Re: A Failed SaaS Postmortem

#45

Post by __jal »

mrmanner wrote: post #33
throwno wrote: post #13

Earlier quoted context omitted.

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

Education is a very "enterprisey" market in which the purchasers are not the users, who are essentially powerless.

Pearson doesn't need to deliver quality, they need to deliver functional + whatever sweetener on the rest of the contract to keep out the competition.

Re: A Failed SaaS Postmortem

#46

Post by lukax »

For one project we did recently we also used only Django and its templating system despite all the fancy SPA frameworks (React and Vue) we used on other projects. This project was a CRUD app with a lot of master/detail pages (tables and forms) and very little dynamic content.

We used StimulusJS[1] for adding dynamic stuff like table sorting, filtering, pagination, form validation and uploads. All tables were rendered server side (including changing pages, which just rendered the table body on the server) and we just used Django Model Forms. Using StimulusJS allowed us to structure the JavaScript code into modules and controllers which allowed us to reuse code on frontend without any complicated frameworks.

There was no requirement for a REST API so doing a SPA would be a waste of time.

[1] https://stimulusjs.org/

Re: A Failed SaaS Postmortem

#47

Post by threeseed »

enraged_camel wrote: post #6

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…

I tend to agree with this.

It's easy to do a database migration, library upgrade and breaking changes when you have zero data and zero users. But once you're past that point then even a minor database migration can be a week of work.

Re: A Failed SaaS Postmortem

#48

Post by privateSFacct »

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.

Re: A Failed SaaS Postmortem

#49

Post by threeseed »

remotecool wrote: post #37

You don't need half of these services/tools. Especially when. You are building an MVP. Your first version should be very simple with very few layers.

I couldn't think of any of those that aren't needed except for Segment. You definitely want monitoring and metrics in place before you launch otherwise you won't be able to figure out issues with your product.

And in the early days it's all about fast iterations.

Re: A Failed SaaS Postmortem

#50

Post by jbob2000 »

ericb wrote: 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.

Post reply on HN