There’s 2 ways to approach writing greenfield code in my mind. The decision between them is simply “once this is shipped, would you accept having to completely

There’s 2 ways to approach writing greenfield code in my mind. The decision between them is simply “once this is shipped, would you accept having to completely re-write it from scratch to add even the smallest feature?” If the answer is no, decent tests will make you go faster. Your commit volume by SLOC will be roughly: 1. Refactoring (~50%) 2. Tests (~35%) 3. Actual impl code for features (~15%) That is, you’ll transact more than three times as many lines of code with your VCS repo just re-writing impl code smaller and cleaner and better organised than you will actually writing code to build the functionality. You’ll spend more than double the adds/deletes/changes to lines of test code than adding features to the product. You’ll implement new features at roughly the same speed today as tomorrow as next year. You can drip feed more devs into the team every 4 months or so to build out velocity further. If you’re willing to throw it away after the first release, you’d be silly not to ditch the tests, forget the architecture and just crank out something that works - best done by a solo dev, deploy each dev in a solo fiefdom from the beginning if you want to throw more devs at the problem. In practice, almost all code is written as a mix between these two views and is slower and more expensive than either approach above because of it.