This approach works well for apps of a certain size and lifespan.<p>Too many full-stack tests can easily lead to non-parallelized build times of an hour or so magnitude.<p>Apps that end up in this state are much harder to change even with parallelized builds. You may be waiting 20 minutes for feedback to know with confidence if a large refactor (or even small one) broke something.<p>Conversely, apps that start off with tons of unit tests and fully TDD may never make it to market. There&#x27;s lots of perfect software making nobody any money, and tons of low-quality software making lots.<p>As with anything, it&#x27;s a balance. 
Yes start off prototyping, if it&#x27;s just you. Only do capybara specs. 
But be really sure that you have a good strategy for scaling up development and the test suite. You have to have people really in tune with the idea of not testing, because they know when to test&#x2F;not test. 
And not just building a mentality of we don&#x27;t do much (isolated) testing here.<p>Likelihood is they are not testing because they don&#x27;t know how to, or don&#x27;t see the benefits or are under too much pressure. It&#x27;s a dangerous line to walk if you are trying to get away with minimum testing and trusting everyone else also understands when you need to and how you need to start having more test coverage.<p>Plus retro-fitting unit tests is normally a nightmare, because the devs never were forced to write uncoupled software.