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.
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?
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.
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.
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.
Independent college consultants also seems like a fairly niche market.
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.
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.
Something that's more geared towards getting you up and running quickly (eg Heroku) might be another story.
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.
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.
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.
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.
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 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?
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.
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.
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.
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.
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.
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.
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.
Avoid adding jQuery & write your own slideUp, slideDown etc. = move slower
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.
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.
Lightweight, real-time updates using the same Rails views already built.
The more I learned, the slower I became. I think everyone who has been doing webdev for some years have experienced that.
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.
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?
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.
>>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.
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.
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.
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.
Automating existing Excel spreadsheets is much easier for solution creation success than automating what you perceive to be a business workflow.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
Your first version should be very simple with very few layers.
And in the early days it's all about fast iterations.
This is exactly the trap the OP fell into.
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.
