But the end result is effectively the same. If you throw in the constraints of what GP mentioned about customer retention, at the Pareto frontier it boils down to the same optimization, just that instead of manually optimizing the specific variables they become latent variables. There is no difference in the resultant enshittification.
If they're optimizing for engagement (the same as Netflix and everyone else), that comes from the the number of active conversations you wind up having. If you're swiping a ton but matches never message you, you'll give up and try another app -- that's not engagement. The more engagement you have from real back-and-forth messages (not spam), the more real-life dates you go on (if you're doing it right). And the more people you meet, the more likely you are to leave.
It's not "enshittified", dating is just hard. People are picky and it's difficult to get a good read on people from just their online profiles. The dating apps just want to keep you engaged and spending money. They don't need to make finding matches harder because they're worried you'll leave -- finding matches is hard enough to begin with. Trying to make it harder is the least of their concerns. They're trying to give you as good of a service as possible, while getting you to pay. So they limit numbers of matches to get you to pay. They're not limiting quality of matches.
Plenty of screenshots and exact step by step instructions. Throwing an "example git repo" with no documentation won't get you any users.
Put your shoes into that of a Heroku/Vercel user. DevOps is usually Somebody Else's Problem. They are not going to spend hours debugging kubernetes so if you want to sell them a PaaS built on Kubernetes, it has to be fool proof. Coolify is an excellent example, the underlying engineering is average at best (from a pure engineering point of view it's a very heavy app that suffers from frequent memory leaks, they have a new v5 rewrite but it's been stuck for 2 years) but the UI/UX has been polished very well.
Yeah working through documentation still. The goal isn’t so much to replace coolify. Mostly born out of my last start up that ran a $20M business, 15 engineers, with about 300-1000qps at peak, with fairly complex query patterns.
I think the single VPS model is just too hard to get working right at that scale.
I think north flank / enterprise applications, would be a better comparison of what canine is trying to do, rather than coolify / indie hackers. The goal is not take away kubernetes, but to simplify it massively for 90% of use cases but still give full k8s api for any more advanced features
It's funny that the software engineers on this forum are all obsessed with building scalable systems that can provide a service at the lowest cost but when it comes to manufacturing all of a sudden it's "we must protect jerbs".
> Twelve voices were shouting in anger, and they were all alike. No question, now, what had happened to the faces of the pigs. The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which.
For many people, code is just a means to an end to solve problems and build. The joy from solving problems doesn't disappear. Would you use traditional (not WebAssembly) assembly to build a web application? Probably not. LLMs make a lot more sense if you think of it as a tool to translate requirements into solutions.
Well, somebody should recreate it. I smell a potential startup idea somewhere. There's a ton of "cloud cost optimizers" software but most involve tweaking AWS knobs and taking a cut of the savings. A startup that could offload non critical service from AWS to colo and traditional bare metal hosting like Hetzner has a strong future.
One thing to keep in mind is that the curve for GPU depreciation (in the last 5 years at least) is a little steeper than 3 years. Current estimates is that the capital depreciation cost would plunge dramatically around the third year. For a top tier H100 depreciation kicks in around the 3rd year but they mentioned for the less capable ones like the A100 the depreciation is even worse.
Now this is not factoring cost of labour. Labor at SF wages is dreadfully expensive, now if your data center is right across the border in Tijuana on the other hand..
reply