The ideas embodied in Shaker design are (in my opinion) almost always correct design rules (the almost being that, as always, you should break your design rules when they interfere with your goal), but aesthetics aside, there is a very relevant message here: in the startup phase, the focus should always be on creating what is necessary, useful, and beautiful. Useful explains itself (though it's often forgotten); necessary is the real Occam's razor of the group, and perhaps the important one for start-ups (i.e. during the initial angel phase, get your critical functionality implemented--a VC won't be impressed by great features if the core functionality doesn't work); beautiful is tricky. It's aesthetic. When it comes to code, though, beauty is usually directly related to maintainability and extensibility. Sure, beauty is in the eye of the beholder, and what I think is atrocious C++ might be beautiful to you, and my beautiful Lisp might make you cry; what matters is that the code is beautiful to the person who has to interact with it.
