> 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 specif

> 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.