[kev_dev]

There is a difference between "table-stakes" complexity and premature complexity. I'd argue that a simple but sane CI / deployment pipeline takes relatively little work to set up and falls under "table-stakes" in that even a pre-pmf team will have a positive ROI in doing it.

On the flip side I have been the one working long nights and weekends reverse engineering code by engineers who prematurely built complexity into the system because they wanted to add a GraphQL api in addition to a rest API. All while in the pre-pmf days, with no value-add to the features that ultimately DID find pmf.

I do generally believe that cleaning-up after the pmf-hunting phase is itself a privilege that many startups do not get to experience, and should be treated as such. I understood the author as arguing that we shouldn't chase shiny things and should ruthlessly avoid complexity in favor of finding pmf. This philosophy is clearly illustrated in the devtools startup he is running. I thought there were some cool ideas there.

[kevingadd]

I simply reject the premise that all problems a startup needs to solve are original problems. Your customers have lots of ordinary problems too, as do you. Sure, you can't justify spending months on building some custom GraphQL infrastructure or the perfect CI/CD deployment system, but your customers do care about things like "when I download and install this software it's not a corrupt build" and "the software's updater works" and "when I pay these people money for their software I get what I paid for and don't get double-billed". These are all unoriginal problems that are nontrivial - ideally your startup solves them with off-the-shelf solutions to save time, but you still spend engineer hours integrating those solutions.

[hgsgm]

Who is putting forth that straw premise?

[kevingadd]

The original author?