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.<p>My choice to focus on the technical is because my lessons basically boiled down to:<p>1. Don't focus on the technical (#1 YAGNI, #2 Ignore software upgrades, and #3 use the tools you know)<p>2. Deliver something valuable to the customers as fast as possible.<p>In other words, I tried to say "don't focus on the technical side."<p>I admit in the article that the technical focus <i>of the article itself</i> was emblematic of why the project failed.<p>> 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.<p>Perhaps I was too subtle on that point.<p>Thanks for all the feedback. I've enjoyed reading the discussion.
> I didn’t help my customers and was too focused on the technology.<p>Somewhat ironic that your Postmortem is highly focused on technology as well :)<p>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.
This is not a postmortem of a failed startup, maybe a failed app.<p>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.<p>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.
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 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.
> I didn’t help my customers and was too focused on the technology.<p>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.<p>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.<p>Actually, if you want it to be a business, the first step would be just use something else out there.<p>Buy > Customize > Build<p>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.<p>After that was working pretty well, maybe he could offer to set it up for some others.<p>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.
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.<p>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.<p>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.<p>Great - I would run the app for folks based on the data they sent me by slack.<p>That worked great - happy users who gave me immediate feedback on the results of the app, I was literally in the run cycle.<p>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.<p>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.<p>Very happy users - usage goes up.<p>More change requests, and deployment approach not great.<p>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.<p>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!<p>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.<p>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.<p>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 <i>very important</i>.<p>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.<p>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.<p>If large portion of your knowledge is frequently invalidated, how do you people not burn out 5 years into your careers?
"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."<p>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.<p>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.<p>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 <i>dropped</i> the Ember app that was 3/4th's done in favor of plain JQuery and Rails 6.<p>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.<p>No one sings of your glorious battles maintaining JS apps in the halls of Valhalla.
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.<p>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.<p>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.
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.<p>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.<p>There was no requirement for a REST API so doing a SPA would be a waste of time.<p>[1] <a href="https://stimulusjs.org/" rel="nofollow">https://stimulusjs.org/</a>
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.<p>I’ve written about it here:
<a href="https://blog.cronitor.io/the-jit-startup-bb1a13381b0" rel="nofollow">https://blog.cronitor.io/the-jit-startup-bb1a13381b0</a><p>The main takeaway:<p>"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 <i></i>really<i></i> want to start a business.<p>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.<p>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.
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.<p>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.<p>On the other hand, certain things become a <i>lot</i> harder and a <i>lot</i> 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 <i>before</i> you cross the Rubicon, so to speak.
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.
> 1. Don't focus on the technical (#1 YAGNI, #2 Ignore software upgrades, and #3 use the tools you know)<p>Adding to this with what one can focus on...<p>Start with an empty mind identifying your customers’ or audience’s problem.<p>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.<p>You just think "ah, let me get this perfect and the customers will flood in automatically", but that's just wishful thinking.<p>In my case I think it relates to a fear of launching public and being criticized and judged.<p>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.<p>Your first version should be very simple with very few layers.
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.<p>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?<p>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.<p>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.<p>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.