We Rewrote Everything in $hotlang, and Our Startup Still Failed
docs.google.comI wonder how many HN readers don’t realize this is satire.
It’s unfortunate that they used the word customer once in the post. Total omission would have been so perfect. The point of the satire is devs navel gazing rather than focusing obsessively on who their customer is and their customers needs and solving that customers problems.
There is a failure mode that has a dev team obsessing over building abstraction layers, tooling, automation etc and not writing a line of code that solves customer problems.
But which startups does this describe, that actually get any media/public attention, or raise any funding, or succeed in recruiting any serious talent? I feel like this is trying to satirise something that exists in the author's imagination but doesn't exist in the real world beyond adolescent first-time founders' early misfires, from which important lessons are quickly learned.
It doesn't seem to be satirising something that actually needs to be satirised, as there is not a significant number of startups in the real world actually operating like this. A startup that operates like this wouldn't (barring a major mistake) get funding from YC or any other competent investor.
The Silicon Valley sitcom is funny and successful because it satirises stuff that really does happen in the startup/tech/VC world (I know, I lived through much of it myself), but it noticeably doesn't stereotype founders as utterly clueless and hapless the way this piece does.
With the sitcom, anyone who knows the startup world can point to real-world people/events on which the people/events in the sitcom are based. I don't think you can say that about this post. It's hard for me to believe the writer of this really knows any significant number of real-world startups.
Well this seems like much more of an internal thing that would really never make it to any sort of media publication. You never read about the internal shit-flinging that happens when a team of engineers has to decide on a stack, but it does certainly happen. At the very least I have personal anecdotal experience of this happening from a couple of companies I worked at.
I can't think of a specific example, but when BLOCKCHAIN was the new kid on the block, every startup and it's mother just threw that word into their company somewhere somehow. How many of them got very far?
This happens all the time at Google, though the mundane details of internal tech churn are not often publicized. Source: am Google employee.
I think I spotted the error they made. There is no mention of machine learning at all!
Ouch. I worked at a startup that pivoted and updated our tech stack along the way. There was some foray into machine learning but not too heavily. This might actually describe more than one of the startups I've worked at.
and no blockchain
I think that they hired people without checking that they could solve basic algorithmic problems on a whiteboard. This was clearly a fatal mistake.
This is just a parameterized version of the post from yesterday: https://news.ycombinator.com/item?id=25198571
> Some tools might be unavailable due to heavy traffic in this file.
The irony of that is, that simply posting a parameterized version gained a lot of traction as well, because the satire just hits home so well (the product is good).
mirror of the old article at https://outline.com/yr7ZBS
I've found: - amazing business running on ball of mud code maintained in an insane way - the perfect architecture, CI/CD, TDD where the business/product has little/no value for the customer
Also, I've seen the same stacks succeed and fail. The only common thing I can see is:
- when the tech team fully understand the stack they're using - when the tech team fully understand the product and business they're building (and can make appropriate trade offs)
There are a bunch of basic tech things. E.g. the underlying infrastructure has to be performance, scale, secure etc. There's also the issue of choosing a tech you can actually recruit for.
I have seen the same, but came away with a different conclusion.
Shoddy architecture and even a bad product can be compensated by marketing, hype or a good sales team, while the most pristine architecture and codebase will not help you at all without any customers.
We technologists often focus on the technical aspects, but in many domains they are the least important part for a startup.
You are in the business of doing a thing, not having an aesthetically pleasing tech architecture.
It is true that having a nice tech stack can make doing your thing easier, but it can also distract you from doing your thing well.
Very good summary. I was going to write a similar thing.
Tech stack is important but (customer) money in the bank is importanter.
Your daily reminder that FB started with PHP. Ship and sell first, the rest can be done later (yes your customer doesn't care that you rewrote your backend to use nanoservices in Go deployed to hundreds of lambda functions).
Facebook was originally a garbage PHP app.
Technically, it still is.
From what I’ve seen it all comes down to org culture. Have a ball of mud that’s a nightmare, but senior engineers who are kind, empathetic, and enjoy mentoring, no problem. Have a perfect architecture written perfectly in $lang by elite devs that don’t have time for mentoring or collaboration, guaranteed failure.
> We opened the floodgates. We shared the project on Twitter and Instagram, posted to HN and wrote a medium post. But, try as we might, no one was signing up.
Later in the post:
> Had we had more funding, we would have taken the time to rewrite our app in $ELITELANG instead. Our startup could have been a unicorn.
Although this is satire, it's something a lot of funded startups do. They think they've solved user acquisition by getting investors money (hey, let's throw a couple thousands at Google/FB Ads, although there are 15+ viable acquisition channels we could try [1]), and spend time on building things in their own bubble.
Also, the launch mention is pretty accurate:
> We launched v2 of our product with a splash.
Wonder if many startups would have better results if flipped the switch and treated product creation as a "launch" (a bunch of big sprints with a deadline) and user acquisition as something they do steadily, over a period of time.
[1] https://zerotousers.substack.com/p/15-acquisition-channels-i...
Hiring engineers based on GitHub stars check, rewriting codebase despite little to no customers check, no mention of anything other than the tech stack check, yep this has to be satire!
Hope this isn’t what’s happening with dark[0]. Saw the early demos and I think the concept is killer, and don’t see why they would focus on a rewrite instead of building on what they have. I never even got asked to pay for it before they pivoted? It kinda felt like giving up and going back to building something instead of marketing and selling what they had.
I say this with much respect for what they built, and someone who also tends toward focusing on the technical when things get hard.
Hey, thanks for the mention! Happy to explain my thinking here.
Regarding marketing and selling what we have: we tried that and it's pretty clear we're missing important bits, in particular packages for common vendors (stripe, slack, etc), and a package for user management, as well as common things like validation. People love the concept (as do you, thanks!), but were struggling to build things because of what was missing.
As we went to build these, the tech/product debt that we had built up during our experimental phase really started to become apparent. We were missing common and expected things like user-defined types (maybe not important for dynamic langs, but we're a statically typed functional language, so being able to create types is kinda important), configurable (or at least changable) HTTP middleware, and a few other things.
The reason for the rewrite is that had been taking long detours around our tech stack for a while. Now that there's limited resources (as in, just me), the cost of taking the long way to everything we build is just a little too high, so it feels like a rewrite (note: just of the backend, the majority of the code is in the frontend and doesn't need to change!) is necessary to get to product/market fit.
I also hope it won't be the death of us. Fortunately, F# isn't a valid value for $hotlang! (Good thing I didn't pick Rust!)
If they don't see the value, people won't even sign up for a free service. You have to build something that people actually want and need to use. That should be your first priority. Is there a real need? If there is, you'll get users no matter what language, platform or stack you are using.
The constant technology change is just self comfort/pleasure and ultimately an expensive distraction. Look how busy we are. Look how cool our work is. In the end, no one cares about that.
It's unfortunate that so many start ups continually have to relearn this basic truth.
Does this really happen?
Yes. Often times tech founders - especially if inexperienced - let the freedom and power of a complete greenfield project with no management oversight go to their heads. They've always wanted to build something in $cool_tech and now nothing stands in their way. That becomes the goal in itself, the business and getting customers and money being a far second.
Their desires could be far more cheaply satiated with a side project, but this way they don't have to use $boring_stack in their day job.
There's an alternative presentation of the same facts:
Not being bound by the traditions of the large enterprise they used to work for, they're free to choose a stack that might help them be more productive. As an added benefit it helps recruitment - against the long hours and (relatively) low pay of startup work, they get to balance a mission and the opportunity to work with interesting technology.
My actual beliefs are somewhere in between. I think the 'fast moving' world of javascript frameworks is a major contributor here as almost anything you chose in the last 5 years is obsolete.
Not all tech stacks are predominantly web though. You might decide to build in Erlang/Elixir. You would be using something that's 30 years old, proven, not going out of fashion any time soon and the right tool for a lot of jobs. You'd be more productive in it than C++/Java, but that's what most enterprises would require.
Productivity is relative. A tech stack that might give you some easy early gains might fail you at 3 a.m. when the site's down and you have no idea how to fix it. Your code might contain some basic security errors that you would have avoided had you gone with a stable, vetted framework, and now hackers have all your customer data (see for example Parler). Recruitment in tech X is much harder because there's nobody around with decent experience in it.
These are all problems that you really don't want when your focus needs to be on the business. By all means adopt new tech where there is a real business need, and by all means avoid obsolete tech where you can, but be wary of the siren call of the cool tech stack when you're starting a new company.
> Your code might contain some basic security errors that you would have avoided had you gone with a stable, vetted framework
On the flip side, stable and vetted popular frameworks also have security problems; and although these problems may be less likely, they are more bad people trying to break them, because when they do, the win is really big. E.g. Windows vs Linux viruses / trojans - I'm not sure if Linux is so much more secure to justify the difference.
Also new tech stacks typically evolve faster and are quicker to fix bugs. It is much faster to fix a problem in a young, less complex product, without having to deal with things like technical debt, backwards compatibility with millions of apps or endless discussions between committers about how it should be fixed.
My point with Erlang though is that there are several mature and sensible tech choices that Big Enterprise (TM) can make it difficult to use.
Yes. Happened to a friend of mine who was doing an IoT startup. The github star metric is actually something the guy used. Unfortunately I don;t think it was his language choice that was the issue rather the github star thingy. Much of the problem is throwing a bunch of excellent engineers together without proper leadership will lead to severe under performance.
Resume based development definitely happens.
I’ve seen it happen.
hahaha HN Satire at its finest!
We used “boring technology” (the stuff we happen to like) and our startup still failed.
Startups fail for a number of reasons. Success depends on removing as many of those reasons as possible. One of those reasons is building on an esoteric tech stack that, while perhaps interesting to the developers, consumes time, energy and money better spent on things like customer acquisition and retention. However even if you eliminate that one reason, there are still many other reasons that will kill your startup.
Reads like a joke with no explanation for needing a rewrite in the first place.
The product itself was not used, dunno how folks assumed a rewrite would solve everything.
>Reads like a joke
Because it is. It's satire. Also posted yesterday with Rust and Haskell.
Narrator: It was actually a joke.