[samus]

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.

[reidjs]

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

[samus]

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.