Is that the obstacle to turning them into businesses? I think getting paying customers is the hard piece of the puzzle? The cashflow will help solve the spag-bowl problem. You can hire a chief refactoring officer :-)

There are a lot of obstacles to me turning my ideas/hobbies into businesses. Yes, getting paying customers is the hardest piece of the puzzle. On my last endeavor, I got way into the server-side weeds with profiles and accounts and billing. It was a neverending spiral because I had designed something far too complicated without a test suite; I decided it could never be completed.

I think my biggest challenge was my consistent inability to form functioning teams around my ideas. I've usually flown solo or been taken advantage of by my team (me doing all the work, them contributing nothing, waiting to see it reach "critical mass".) On the last go, I even offered a guy an equal partnership, but that was not enough and he never committed. It tempts me to think my ideas were not viable when I could never convince my peers to jump on the bandwagon. I always had users who seemed to get value out of my services, and that kept me going.

I've never gotten a huge amount of attention or gotten funded, and frankly I like the autonomy, so I have never sought any funding. Of course, that means if I have any hope of getting financial rewards from bootstrapping my hobby work, I've got to be very organized, which I never have been on past projects.

For my current project, I've decided to open source my new codebase with the AGPL. In the business I'm looking at getting into, open source is common with the popular services, but these projects rarely get any outside contributors. Hopefully I can at least get code reviews, bug reports, and maybe even some code contributions if followers don't mind assigning their copyrights to me.

On this new project, I've got a really tricked out client-side JavaScript development environment with Gulp, Webpack, Karma, and Closure Compiler. I'm really happy with how simple and powerful the build system is, and I'm hoping that by making it easy to build and test, I can attract devs to join my team.

Why do you think you need TDD to write logical and tight code? It's one way, but there are less drastic ways to the same ends.

Just for me (YMMV) I find that when I write untested code, I make too many large cognitive leaps in my changes. My code looks good at the time and it usually looks well-factored, but entropy and shortcuts always seem to creep in there. Pile all those errors up over a 5 year timespan on code that slowly accretes since I'm maintaining it on my leisure time, and I always wind up with really untrustworthy code and occasional frustrating regressions when I make changes.

The test suite with good coverage gives me confidence that the code continues to work as I make changes (no regression bugs.) It's about having complete trust in my code, no second guessing, and no time ever wasted in a debugger chasing down issues.

And, I want to be able to cut a build at any time as long as all of my tests pass and feel confident I'm not shipping a broken build. I've never been able to do that on any project in the past, and I think it will be one mark of success on this new project. I've implemented a mini feature toggle system in my build scripts to make that possible.

Finally, I'm using Closure Compiler with full optimizations in my production build to do minification. Closure Compiler itself can (theoretically) break the build with its over-aggressive optimizations, so part of having a complete coverage test suite is being able to run the tests against the production build and catch any bad optimizations that CC makes. Because of my architectural choices, I REALLY need that test suite.

Do I need to write the tests before the production code (do full TDD) or can I write tests after? Well, I am the type of guy who won't write the tests after because I always want to move on to the next fun thing. I just force myself to do it, and take my medicine up front.

There is a big difference between "untested code" and "tdd code"

There are two different ways to test code.

1) Do the TDD thing. Write 1 test. Code to pass. Repeat.

2) Write code that works. Iterate on it. Refactor, clean it up. Then write some tests that test the final product.

You can have tested code in both cases, but I claim the code from #2 will look cleaner than the code from #1.

TDD can give you higher quality code... which really only delays the inevitable refactor once the true specs and user needs are discovered. I usually write quick and dirty implementations (after doing some API design on paper) and see if it has sticking power... then write tests and often times rewrite the code entirely in TDD style once more is understood about the problem.

And when you haven't worked on a project for a while, improving the test coverage is a great way to get back into it.