by jubjubbird on 12/18/19, 6:41 PM with 134 comments
by mblayman on 12/18/19, 10:34 PM
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.
by jahbrewski on 12/18/19, 7:02 PM
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.
by Crazyontap on 12/18/19, 8:12 PM
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.
by cddotdotslash on 12/18/19, 7:19 PM
by tschellenbach on 12/18/19, 7:02 PM
by ben_jones on 12/18/19, 6:57 PM
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.
by omarhaneef on 12/18/19, 7:52 PM
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.
by privateSFacct on 12/18/19, 8:49 PM
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.
by amitmathew on 12/18/19, 7:48 PM
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!
by hvasilev on 12/18/19, 7:40 PM
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?
by npollock on 12/18/19, 8:56 PM
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.
by hogFeast on 12/18/19, 7:38 PM
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.
by ericb on 12/18/19, 7:08 PM
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.
by briandoll on 12/18/19, 6:56 PM
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.
by lukax on 12/18/19, 8:47 PM
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.
by encoderer on 12/18/19, 8:16 PM
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."
by tnolet on 12/18/19, 8:54 PM
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.
by Disruptive_Dave on 12/18/19, 8:52 PM
by rajacombinator on 12/18/19, 9:55 PM
by enraged_camel on 12/18/19, 7:06 PM
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.
by tunesmith on 12/18/19, 7:39 PM
by jiux on 12/19/19, 1:28 AM
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.
by edoo on 12/18/19, 9:06 PM
by jlis on 12/19/19, 9:09 AM
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.
by remotecool on 12/18/19, 8:11 PM
Your first version should be very simple with very few layers.
by tekkk on 12/19/19, 12:44 AM
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.
by sky_rw on 12/18/19, 11:34 PM
by ykevinator on 12/19/19, 1:58 AM