Prototyping can be a great way to explore the solution space. Just make sure to learn as many lessons as possible and then burn the prototype with fire.
Startups almost by definition face a literal deadline. They critically depend on people who code 80h per week instead of partying.
The impact of UI changes can be hard to measure. If the deployment platforms are very heterogeneous, it's literally impossible to test all scenarios. In these cases it makes sense to roll out slowly and find ways to measure the impact. Or to limit the fallout.
Sometimes, simple solutions get the job done perfectly well and run for years with manageable upkeep. It's a slippery slope though.
It can be very difficult to capture the domain knowledge and the insight of developers and operations people in documentation. Documenting will bog them down instead of getting things done. Managing the bus factor and training up people ahead of time is crucial.
I find it hard to believe that the most successful startups are the ones who code 80h per week unless you guarantee that the output of the code is big $$$
You have to convince your stakeholders that further investment is worth it. But I also think that the "go big or go home" strategy comes from seriously messed-up incentives. It might be justified if the margin is very low or if aquiring a big user base for other purposes is the actual goal.
Probably not what the parent poster was talking about, but fear is a great inhibitor. Excessively high standards for documentation and depth of scope might inhibit less experienced engineers, and nitpicking about scope is a pointless waste of time that ends up being a managerial excuse for more meetings especially if it's brought up endlessly when the core feature does not yet work. This promotes a culture of fear which can paralyze a team of engineers and all you end up getting out of them is the bare minimum.
The “move fast and break things” context. Ship it now, make butt load of money by over promising and under delivering. No need for testing or docs. Adding half baked features, you only live once.
Startups almost by definition face a literal deadline. They critically depend on people who code 80h per week instead of partying.
The impact of UI changes can be hard to measure. If the deployment platforms are very heterogeneous, it's literally impossible to test all scenarios. In these cases it makes sense to roll out slowly and find ways to measure the impact. Or to limit the fallout.
Sometimes, simple solutions get the job done perfectly well and run for years with manageable upkeep. It's a slippery slope though.
It can be very difficult to capture the domain knowledge and the insight of developers and operations people in documentation. Documenting will bog them down instead of getting things done. Managing the bus factor and training up people ahead of time is crucial.