> I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section.
I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more.
> The TLDR is there isn't a one-size-fits-all.
That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion:
> Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs.
Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.
> That's what I mean - the author gives no prescription.
Are you expecting a prescription? If so, what could that look like? Specific technologies? When specific technologies are appropriate?
> Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF.
I don't quite understand this. A bakeoff is meant to give you space to figure out what technologies are appropriate for the service you're building for your users and taking into consideration what your developers like. It's a collection of proof-of-concepts so it's a quick and lean way to get data on what's more likely to succeed for you. I can accept that the technology doesn't make a product, so focusing PMF is important, but you also don't want to pick something complex that you can't afford to manage as you scale.
The worst thing I see happening is you reach PMF and need to continuing scaling, but you hit a high complexity wall that you can't move past till you manage it. All that unnecessary complexity you took on and didn't invest your already limited resources is now tech debt that's oppressing your forward momentum. Bakeoffs can steer you towards the simplest tool you need to deliver your product so that it can stay out of your way so you can focus on iterating and developing your product.
> The rest of us will use React, which is roughly 80% as good as the optimal solution.
How are you measuring this? A lot of the evidence for using a technology and running with it without managing the complexity turns out badly (see The Reckoning series by Alex). And React is a high complexity tool that requires a lot of continued management investment.
The thing that appeals to me about doing bakeoffs to find the simplest thing for my product is not that it'll be the most optimal; it'll be the cheapest to maintain. The less complexity you have, the less you have to invest in managing it.
> I just don't think many of us are Google or Facebook.
I agree. That's why I think it's best to pick the simplest tools we can afford to manage so we can get on with building our products. Facebook or Bluesky or Airbnb can afford to build their products many times from scratch and they can pay to maintain whatever complexity they take on.
I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more.
> The TLDR is there isn't a one-size-fits-all.
That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion:
> Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs.
Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.