A Failed SaaS Postmortem | Hacker News Reader

A Failed SaaS Postmortem

mattlayman.com

225 pointsjubjubbird134 comments

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.

Great Article! There is far to few of these in the world. So many companies go under but keep their website and linked-in in a state that looks like they still exist.

Is this a postmortem postmortem?

Ha! Yes, I suppose it is. :)

How do you think it went?

Did you look at competition? CollegePlannerPro seems to fit the same area you're going for, did you differentiate from what they were doing? I just was curious if there's a market fit for something like this, always thinking of running w/ a failed idea that still has runway, but I have so many half-finished MVP's it's not even funny.

I've got a bookmark folder of startup ideas to clone. So far I've cloned 0. Too busy freelancing. But I usually like two types of businesses :

1. Simple w/ multiple competitors doing 5-10k+ per month, like uptime monitors, wp management, social media posters/schedulers, crm's, project management.

2. More complex apps usually vertical specific with nobody really competing or filling the void, or the ones that are out there are shitty. Whether an idea I had, or someone else on a forum/reddit/hn etc or failed.

Yours would've in my mental compartmentalization of 'apps to maybe clone/build' fit into the second category, but looking at what's out there, I don't think a 1 person team could really compete w/ CollegePlannerPro - seems to have most things you'd need as an IEC.

I'm just wondering if you saw what they were doing at any time and thought, well shit. I'll never be that good, might as well give up. (I've had that thought a lot!).

tldr; Have you seen College Planner Pro, did seeing a polished competitor like them have any influence on shutting down?

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

I think the key is getting out of the comfort zone and do something completely different. After a hard day´s work as a developer it is just too tempting to continue developing, habitually, instead of doing inconvenient other things.

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.

The product is the second or third or fourth most important thing. The language not important. Being upto date on package the least important.

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.

Bingo. The teaching and counseling crowd are non-technical for the most part and they're not concerned with Django or Ember.

Independent college consultants also seems like a fairly niche market.

One of the craziest parts of this article to me is the sheer number of technologies he picked right off the bat to implement the service. Datadog? Digital Ocean? Wal-e? If he had gone with a cloud provider like AWS he probably could have cut that list by 2/3 by just using built in solutions.

I get your point, but for what it's worth, I moved a service from AWS Lambda to a Digital Ocean Dokku box and the amount of complexity I had to deal with went down dramatically and hosting costs dropped (I was getting enough traffic to break out of the free tier).

Or a barebones box from Vultr or Linode then log errors out to stdout, slap an email address on the page and there's your logging and error system.

AWS is massively overcomplicated for an indie SaaS business, and it costs way, way too much.

You can have a box with plenty of room for $5 - $10 / month and it takes about 25 seconds to launch it.

I had 20k concurrent users with a $5 server and Cloudflare. Other people are using serverless solutions, which drive the price even lower.

The author stated as much: keep it simple and boring. He thought he was going boring for a SaaS, but he went way too exciting for what an indie SaaS needs.

> Or a barebones box from Vultr or Linode then log errors out to stdout

So instead of talking with customers and growing your business you are busy wasting your time installing a web server, database server, configuring build tools, etc?

Getting root access to a barebones linux install is conceptually "not complex". But that is only because it pushed all the actual complex stuff up the food chain and into your head. A head that needs to be thinking about everything but how to configure apache or the load balancer or postgresql.

> keep it simple and boring

Installing a web server from a package manager and configuring it in a repeatable way is not simple and boring. A single person startup doesn't have the bandwidth to do that.

I don't know if I've been doing something wrong now. For my personal web apps, I've always just installed Nginx, Let's Encrypt, and then a docker image of my application/DB. Spinning this up on a fresh Ubuntu Server install takes less than a half hour if I had to guess. Nginx to force TLS and proxy pass to my docket image.

I'm not trying to be rude, just genuinely curious if I'm missing something complex that could be making my services less secure.

Heroku does that in 3 minutes. And maintains & updates that stack for you. And gives you deployment automation etc. For $7 a month.

Exactly. Deployment is merely a "git push" away. It is amazing how simple it is to get started building a new product.

Every second you spend configuring web servers and stuff is a second you should be spending adding value to your business.

Deployment /can be/ a git push away, but that's only on the extreme end with things like heroku. You mentioned cloud. Cloud has cost sinks every so often (in terms of time).

Cloud has much value but please dont' consider it a panacea.

You can get a lot of value out of those 30 minutes installing a webserver; and it can save you a significant amount of cost.

Not to mention when you want to actually scale you'll see the reason why pretty clearly, unlike in cloud providers where inefficiencies can just suck up money until you notice.

And I definitely take exception to the "every _second_ you spend doing something other than business is a waste" because by that logic I shouldn't use the bathroom or take time to have a coffee.

Businesses don't exist to save money. They exist to deliver value.

Your goal in a startup shouldn't be all about saving money like some cheapskate penny pincher. Penny wise, pound foolish.

Worrying about $100/mo in heroku bills instead of $10/mo "bobs budget webhost" bills is a waste of time. If your startup cannot afford $100/mo or even $1000/mo in infrastructure costs you probably should exist. Especially given smartly spent infrastructure costs (eg: using heroku) let you deliver value far faster than cobbling together infrastructure yourself.

Penny wise, pound foolish.

I think this heavily depends on your model. What if you're sticking a hundred darts in the dartboard to see what gets traction? $10K a month is going to hurt.

You are so clueless and off the mark I wonder if you're trolling or are some teenager that watching a lot of entrepreneur videos.

A dollar saved is a dollar earned. AWS is a terrible choice unless you have a huge amount of free credit. Also, an income of $4000/mo puts you into the average American household income bracket. Why would you throw away 25% of that on infrastructure to save 2 hours on the front end?

Not every startup needs to be the next Instagram. There are tons of people out there happy with their small and medium sized SAAS companies which have allowed them to leave the rat race.

Stay away from Heroku. The team has recently all moved over to work on Salesforce Evergreen and is only barely keeping the lights on.

Source: I worked there for years until very recently for this reason.

You can use CapRover and additionally save the steps of nginx and Let’s encrypt. On DigitalOcean exists even a 1-Click App of it, so it’s trivial to get CapRover running on a droplet.

Yes, you'll spend some 2 days setting all services, testing, setting backups and alerts, testing again. Add another day if you want redundancy.

And then, every 4 to 8 months you'll spend some 2 hours making sure everything is working right and up to date. If you get into another user-base class (like, from 100 to 1000, or from 1000 to 10000), you will spend all those 3 days again.

Compare that with cloud services, where you'll spend a week up-front, and 2 days at random when something changes. But well, that comes with the bonus of a much higher price and a slower development speed.

There is the safety to know that you can move between user-base classes without any cost. You'll just be taken by surprise when it actually happens and you discover that those 3 days are a rounding error compared to what it costs to update your software.

And building on barebones keeps all options open.

If you go big and realize an IaaS solution is right, great, you are ready to go on to IaaS with no trouble

If you IaaS from the beginning, you've cornered yourself and have to build your way out.

How are these scenarios any different from each other?

You are not ready to go IaaS with no trouble if you've already built your own. It's just as hard to do that as going from IaaS to your own custom infrastructure!

This comment reads as if you worked with the cloud in 2009 and haven't been back since. It doesn't take a week to setup a service. In fact, you could spin up everything you need in maybe an afternoon to get you a fully-working, TLS-backed API and website. From that point forward, everything is fully managed and you don't need to deal with Let's Encrypt binaries and stdout logs, etc.

Your first paragraph is exactly what the OP of the article did who is now writing about how it failed.

”So instead of talking with customers and growing your business you are busy wasting your time installing a web server, database server, configuring build tools, etc.”

Oh come on. It takes maybe an afternoon of work to do everything you’ve described.

Let’s say you’re utterly clueless about all aspects of sysadmin, and you need to learn how to do it from scratch: 2-3 days, tops.

No matter how much you pad the schedule, it’s far worse to have to learn 5-10 “managed solutions” to do what you can do on a single VPS with an Ubuntu install.

Can you do it all with something like heroku? Sure, but you’ll probably spend at least an afternoon learning heroku (speaking as someone who has extensively used heroku, it’s not a panacea.)

If I heard this objection in the real world, from a dev who worked for me, I’d be seriously reconsidering my hiring decision. You’re either irrationally afraid of basic syadmin, or you lack fundamental knowledge.

> or you’re just being lazy

LOL. Good developers are the most lazy people on the planet. Laziness is a virtue, not a sin!

If my developer told me our company could outsource all our sysadmin tasks to some third party I'd be a fool to not listen. If I was a developer and my boss called me lazy for trying to help the company move faster (which is far more important for a startup than saving a few bucks) because boss-person is a penny pincher, I'd reconsider my choice of employer.

A startup focused on pinching pennies is doomed from the start.

The reason startups die is that they run out of money. Ramen profitable is a thing, and ramen costs less than the kind of outlays you're describing.

If you've hit a seam such that each feature you develop nets you more revenue, you'd be a complete idiot to optimize for costs. But a company in search of a business model hasn't gotten that far yet.

Lazy when it counts.

This mantra that good engineers are universally lazy is absurd. I absolutely will find the easiest way to solve a problem... as long as that problem can tolerate that solution.

IaaS is a minefield and plainly saying IaaS >> barebones is absurd.

Engineering 'magic' is great until you realize you need something slightly different but you are locked into their framework, system, whatever. You then have to spend a bunch to engineer yourself out and end up with an inferior solution when you could've just done it 'simple' the first time.

An early engineer should have zero trouble pulling up an Ubuntu box, installing Nginx and Supervisor and pulling some default configs from StackOverflow. I have been re-using the same config for both for years now.

Great developers are not lazy. They close brackets and leave no debt. They are lazy in the sense that they implement the least features required because they know the pitfalls of over developing. They are lazy because they leave at 5 but only after finishing their work.

A great developer doesn't ask his boss to hire a third party to manage the server. They ask the boss to hire someone in house because getting anything non-basic done over trouble tickets is a non-starter. A great developer can handle pinching pennies because they use open source at home.

> Installing a web server from a package manager and configuring it in a repeatable way is not simple and boring. A single person startup doesn't have the bandwidth to do that.

Indeed, which is why there were no web startups before about 2010.

You're wrong. I've been doing it for 11 years, and it really is simple and quick. Package-managers does most of the work and there isn't much config necessary to start out. You should give it a go.

For a startup, something like heroku is perfect. Course, my opinion is formed based on data 5 years out of date. Now days I'm sure there is something that abstracts things even more.

I think it will be more like replace 2/3 with AWS* service.

The items on his list are on average easier to set up and learn than the equivalent on AWS.

Something that's more geared towards getting you up and running quickly (eg Heroku) might be another story.

I 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.

One of my colleagues (a backend engineer) was a CTO of a failed startup, he always talks about it. So one day I decided to talk to him about his experience, and it quickly became clear, that he as a CTO, was only focussed on technical work, complaining about how engineers build solutions that weren't scalable. How he fired people because they didn't write the code he wanted.

When I talked about a startup I worked at, and how most of our backend was written in Node.js, and about how we tried to improve our UI to make it more customer friendly. He quickly dismissed all of it, blamed Node.js for failing our startup, and told me customers don't care about a pretty UI.

It was then when I realised why his startup failed, at no point in time did he ever talk about the actual product they were building, or what problems he was trying to solve. He only talked about technical work, and about how that was his main focus. He even thought making our UI customer friendly equalled in just making it pretty.

> 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 <h1> 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.

I don't develop web apps for a living but even I would have thought the obvious solution is to first get v1.0 up in Rails/Django or whatever you know and then try new frameworks etc.

Actually, if you want it to be a business, the first step would be just use something else out there.

Buy > Customize > Build

It would have been interesting to see what his wife uses at the moment. I think he could have given her functioning software by just taking her excel sheets (for instance, if that is what she used) and just put them online with Google, and connected them with Scripts and an interface with Forms.

After that was working pretty well, maybe he could offer to set it up for some others.

Only after that would he selectively take pieces of the system and change it to Django. So first, have the forms in Django talk to their sheets. Then have their sheets dump into his reporting system etc.

The "Buy > Customize > Build" logic holds for supporting software. When it comes to the core of your business, Buy is usually not an option and also doesn't give you a competitive advantage. Also the effort of Customize can often be greater than the Build path in short order. I've experienced this with one startup that thought that it made sense to customize a Drupal CMS for a bespoke experience with hybrid human/ML curation.

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 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?

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.

"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.

When he started talking about the tech, I could tell.

If you want to make money: make things that other people want. It is great fun to tinker with the latest JS framework...but that is what you want to do, not what other people actually need.

Btw, just generally, developers could do with understanding business better. At most places, business is just something that gets in the way of fking around with Haskell or whatever.

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 will, but we are moving twice as fast now.

No one sings of your glorious battles maintaining JS apps in the halls of Valhalla.

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.

Totally agree you don't need jQuery. My criteria for inclusion was "does it make our development even slightly faster, on balance."

The answer was yes in this case. Perhaps that's just the familiarity of it, but at the end of the day, faster is faster.

I'd say my new philosophy is: let our competitors optimize for purity or trendiness or even render time while we optimize for development speed.

Look here son you don’t need jQuery. Go outside, dig up some Silicon, bake up some wafers, design and manufacture a cpu, strap it to a motherboard, hand-smelt some housing, throw some coal in the generator, write an OS, handcraft a browser, and use plain vanilla HTML/CSS/JS. Fucking kids these days with their _frameworks_

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

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

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

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

Plenty of people create rats nests using frameworks, too. Would forcing the “most senior but not the smartest” person to use a framework they don’t like really have fixed your problems?

A framework at least encourages a coherent pattern.

Even non-framework people make frameworks. Just implicitly. At least a marginally good “real” one probably had somebody think hard about it and a great one has a community around it with plenty of devs that can jump right in on your project. All of them will have better documentation and you can get questions answered on stackoverflow. No such luck with the ivory tower anti-framework bozo’s pet framework.

God I’ve worked for too many startups where some “anti-framework” bozo declared frameworks as unneeded bloat.

Avoid these startups at all cost cause whoever hired the anti framework bozo is also a bozo and whoever hired that bozo is also a bozo. Fish rots from the top.

Not a good look for a startup with more important things to do than pushing far-out technology agendas.

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?

I work for an enterprise company with more than 70,000 employees. Standing up a team and getting them productive in 2 months is basically unheard of at this level.

This community is heavily biased to small companies, startups, and students. I'd be hesitant to judge their approval as affirmations that you are doing the "right thing".

> affirmations that you are doing the "right thing."

I'm not really looking for approbations--I'm happy to play this business game with a speed optimized team and see how my strategy fairs on merits against competitors maintaining two apps to my one. I'll make that bet all day long.

I'd say hold up and question your assumption that there is a "right thing" at all.

In terms of the perception of what is the "right thing", and the startup bias of this place, that could be true. I'd add though, that there's a reason houses are not made of rebar reinforced concrete. It's too expensive to work and rework. From that, I'd generalize that certain architectural patterns work better in some cases, and in others they are overkill. Wood works fine, and it is faster and cheaper to build with. And if you have to knock it down, you can rebuild the next one for cheap too. Neither is "right."

It depends a lot on the customers. The tools we make are mostly B2B and are "premium". We are never first to market, but our tools are trusted over our "competitiors" ( I have put that in quotes and one of our competitors owns 30% of our firm), and this means get more customers because of the trust in robust tools (rebar reinforced concrete).

Stimulus Reflex is probably what you want. https://github.com/hopsoft/stimulus_reflex

Lightweight, real-time updates using the same Rails views already built.

Soo.. the response to OP's post regarding the burden of maintaining systems built with JS frameworks is.. yet another unknown JS framework that will cease to exist in 3 months from now on?

Not exactly.

The Framework is Rails focused in that 1) Event handling is setup by Stimulus (a basecamp js framework), 2) Rendering is done server-side, transparently sent client side via ActionCable with dom-diffing automatically applied.

It's a way of achieving a real-time app while still maintaining performance and reusing your Rails server-side views.

I have a couple of questions for you:

1. Was your Rails app solely an API or did it also serve HTML/CSS on first load?

2. Did you build a reusable component framework for your Ember app?

3. Did you follow something like JSON API[0] and use EmberData to hook into it?

I've found that Ember apps with a Rails backend API actually fit together pretty nicely. Don't get me wrong, I like simple. I don't even have a single line of JS on my personal site nor do I use any libraries to generate it (I wrote my own static site compiler), but I've seen JQuery in practice and it makes me unhappy as the app grows because so often things get inconsistent in terms of UI. Plus there seems to be less overall structure of the frontend.

[0] https://jsonapi.org

1. Yes, just API/SPA 2. Yes 3. Yes

The decision is purely pragmatic, not about taste, purity, or anything else. If I can develop faster up to the point where I have the budget to worry about those other concerns, that would be a win.

I was so used to building SPAs and APIs, that it seemed the default to me. But I always felt it was slowing me down, I had to switch between multiple terminals, multiple editor windows, things had to be tested twice (on both FE and BE). I dropped that for just plain old MVC on the backend, and I find myself moving a lot fast now. I still need some JavaScript for things like dropdown, or the occasional AJAX call, but other than that, I actively try to avoid it.

This is very true for me too. I used Vue frontend and php backend, it makes it more fun to work on the frontend, but it's definitely slower for me compared to just rendering everything serverside.

The more I learned, the slower I became. I think everyone who has been doing webdev for some years have experienced that.

In my recent project, I try to do as much as possible through serverside rendering, obviously there are things that still require JavaScript. I just extract those out as components. Right now I’m using WebComponents, but you can easily use Vue if you wanted.

Just treat it as a secondary layer for HTML, not the primary one.

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

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.

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 wouldn't some big player like Pearson just come in and roll him? They can easily hire a bunch of guys to copy what he's doing and then leverage their existing relationships with the education industry to lock him out.

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.

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.

Ultimately, you are right. Innovative proprietary tech just doesn't matter in software. I want to believe it does, so I don't feel that I've wasted my life learning to build software. Seems like hardware and medical are the only places where innovation creates value. A software company being no different from a salty snack company is sad to admit. On the other hand starting some new brand of potato chips or soda can't be any worse than making a webapp to squat a SaaS microniche that you don't care about.

network effects and customer base are much more powerful moats than choosing one technology over another or developing your own.

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.

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).

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?

Google (search), Microsoft (OS, especially early on), Dreamworks (rendering, animation), Oracle (database, early on before OSS database got good).

It's the exception, not the rule though.

Microsoft licensed their early OS. Dreamworks led with SKG and the tech followed. Oracle always had meaningful tech competition and fought with sales/marketing.

Google is pretty true, though.

Ksplice, kdb+, Google search, Mathematica

Yes. Any tech acquisition over 1B is never done for customers. For example deep mind from google.

Just this week Intel bought Havana labs for 2B due to their AI chip hardware.

Also, look at what AMD is doing to Intel. This is pure tech play (and pure moat).

The underlying rule in play, is that the tech business is bound to "leapfrogging", I.e. a better technology can destroy companies almost overnight (see the case of Nokia). So hard tech is more important than customers.

Look what Tesla is doing to GM, etc.

I said software business, so I'm not sure why you're bringing up AMD or Intel.

As for billion dollar acquisitions.... Visio, GitHub, Yammer, LinkedIn, Instagram, Parse, etc.... shit-tons of them are done for market reasons.

Right, network effects are also moat.

But I thought you said nobody ever did large acquisitions for customers....

weird, I must be thinking of somebody else. Since it would make no sense for you to try to take both of those sides at once.

Why not. There are no sides here. There are different moats. If you want a more elaborate view:

http://reactionwheel.net/2019/09/a-taxonomy-of-moats.html

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."

This is bad advice. If you have a really good idea and a company in the same space with the money and resources to beat you to market sees it, it's very possible they will bring it to market before you.

Large companies like Google and Facebook will regularly feign interest in someone's app or idea (that they might want to purchase), only to roll it out themselves.

99.9% of entrepreneurs are never going to actually compete against Google, Facebook, et al. And if they do, it's actually not that hard because the entrepreneur's approach will be completely different.

That's the whole point of the advice: stop worrying about being copied. It's a fake problem.

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.

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.

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.

>But if you want to build a SaaS business, keep focused on building the _business_. The app, it turns out, is the easy part.

This. The crux of his issue is focusing too much on tech and not enough on the end user along with the other "Big Design Up Front™" pitfalls.

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.

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.

> The app, it turns out, is the easy part.

Automating existing Excel spreadsheets is much easier for solution creation success than automating what you perceive to be a business workflow.

> The app, it turns out, is the easy part.

I dunno, I don't know anything about self-driving cars, but when the people making self-driving car SaaS say the software part is difficult I tend to be inclined to believe them.

Even if these sorts of entrepreneurship cliches are true in most cases, I don't think it's a good idea to use them to write people off without doing any critical thinking.

One person is making a self driving car company in the evenings and weekends and you think the software will be the hardest part? Someone could figure out the software perhaps but selling it to an existing car company would be near impossible but less impossible compared to creating brand new car company and getting them certified in a state.

Oh, I've fallen into this trap - not the technical debt so much as the getting so focused on building something cool that I ignore the business side of things (small things, such as, does anyone want this thing?). So in the end I wind up with something only I think is cool :)

On the upside, my last failed SaaS product was at least partly responsible in landing me my current job. At the time of my interview I had not yet fully given up on it. I mentioned it (the failing SaaS) because I had learned a few relevant technologies while building it.

One of the engineers interviewing me pulled it up on his laptop and said, "Show it to us." So most of the interview turned into a combination demo/technical discussion of the project. They ended up skipping the whiteboard/coding portion of the interview (which is good because I suck at those), and I ended up with a (very good) job offer. The job itself has turned out pretty good so far, too.

So, I've got that going for me, which is nice.

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/

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."

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.

I was guilty of this. Spent far too much time optimizing database indexes and far too little time actually talking with customers and validating new ideas.

Technology choice is the least important part of a startup. Pick what you know and roll with it. Make sure the first developers you hire "get" startups and aren't in it to tinker with their pet projects or push some bozo agenda (eg: don't use js frameworks because.... they are "bloat". don't use third party libraries because they are "security risks". don't use the cloud because RMS said not to). Developers with strong "unorthodox" opinions about technology are toxic to startups.

The "bozo agenda" is a great point about early tech hires. I bumped into a few over the years and they can totally kill your dev team and young business.

Tell me about it. It is even worse when they are protected by the founder, who is either non-technical and considers the bozo a "rockstar" or is technical and brought the bozo in because of past relationships (friend, coworker, etc).

The bozo gets protected by the founders and all future developers have no career path, no say in the technology, and get to swim in the sea of an opinionated hot garbage codebase.

People who leave big companies for startups to escape the politics eventually get a rude awakening. Startups, especially very small startups, have a whole different set of frustrating politics. Not even sure which is worse to be honest.

While I recognize the audience and the writer's background, the fact he spent the first 75% talking about his stack is indicator #1 his "business" wouldn't work. Just cause you can build a boat doesn't mean you can sail.

Not convinced he learned the lesson. I see nothing about why the product failed just a bunch of blah blah about tech stack choices which are almost 100% irrelevant for a pre PMF product.

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 patched up before you cross the Rubicon, so to speak.

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.

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.

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.

I’ve been having a fantastic time lately with Rails and a bit of Stimulus for bits that need the extra interactivity offered by Javascript. I don’t think it’s a coincidence that both of those came out of 37 Signals, who are laser focused on delivering just enough software to give customers what they need to do their job.

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

Adding to this with what one can focus on...

Start with an empty mind identifying your customers’ or audience’s problem.

Then answer with the technologies that make the most sense to solve it.

I've been doing firmware for the better part of a decade and I used to do PHP MVC web stuff before that for a megacorp. They used Yii which had ActiveRecord. You could have it scan your entire db and generate all the models including relations, then abstract from those models for the business logic. Any db changes... just re-run the generation. I can make a complex 15 table database and all the models in a few hours and jump right into productivity. Seems weird people are still going through problems with this today.

Oh boy I can relate to a lot of things in this article. Like switching technologies back and forth, focussing too much on polishing instead of just delivering the damn thing.

You just think "ah, let me get this perfect and the customers will flood in automatically", but that's just wishful thinking.

In my case I think it relates to a fear of launching public and being criticized and judged.

I'll do it better on the next launch.

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.

Monitoring and metrics don't matter at launch when your scale is at most a handful of b2b clients. For an API-as-a-service? Maybe. But humans will be quick to let you know if they hit issues. More importantly, if you're fulfilling an important function for them, the number of 9s in your uptime is the least of their concerns.

This is exactly the trap the OP fell into.

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.

"Software as a Service" implies a business. I don't think this was an attempt to build a business. If it was in some skewed sense an attempt at that, then the entire post save for the "Ignoring customer development" section should be deleted.

Great article thanks for sharing. I would love to hear the business side. How did you get leads, what was your sales process etc?

Reply on news.ycombinator.com