I wonder how many HN readers don’t realize this is satire.<p>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.<p>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.
This is just a parameterized version of the post from yesterday: <a href="https://news.ycombinator.com/item?id=25198571" rel="nofollow">https://news.ycombinator.com/item?id=25198571</a>
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<p>Also, I've seen the same stacks succeed and fail. The only common thing I can see is:<p>- 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)<p>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.
> 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.<p>Later in the post:<p>> 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.<p>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.<p>Also, the launch mention is pretty accurate:<p>> We launched v2 of our product with a splash.<p>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.<p>[1] <a href="https://zerotousers.substack.com/p/15-acquisition-channels-i-discovered" rel="nofollow">https://zerotousers.substack.com/p/15-acquisition-channels-i...</a>
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.<p>I say this with much respect for what they built, and someone who also tends toward focusing on the technical when things get hard.<p>[0]: <a href="https://blog.darklang.com/new-backend-fsharp/" rel="nofollow">https://blog.darklang.com/new-backend-fsharp/</a>
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.<p>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.<p>It's unfortunate that so many start ups continually have to relearn this basic truth.
Reads like a joke with no explanation for needing a rewrite in the first place.<p>The product itself was not used, dunno how folks assumed a rewrite would solve everything.