Go further. One test is worth ten thousand opinions. What are a thousand tests worth? Plan to build and deliver an expedient first version, then have a techn

Go further. One test is worth ten thousand opinions. What are a thousand tests worth? Plan to build and deliver an expedient first version, then have a technical debt jubilee before building the second. Build v1 in the most reasonable expedient (including not-scaled-up) way to deliver a reasonably full first feature set. See how it runs, what the users like/dislike/need/want, where are the rough edges both externally & internally, what the load cases look like, on various components, etc. You'll find 80%-90% of your surprises with this. Now, use your quickly-won knowledge of your actual system to plan and build the durable and scalable version. Despite my intrinsic approach having always been about planning, generalizing, etc. (premature optimization?), I was fortunate enough to be in a situation in one startup where I decided to do this, and it worked out amazingly well. V1 got out fast, without worries about tech debt. Building the 2nd version based on actual knowledge and and the v1 tech debt jettisoned, allowed a 'real' version to get out faster and better. There may be some problems with mgt politics, and it interfered in the above product also, but it does have much to recommend it.