If you're using a dynamically typed language I'd suggest very trivial (1-5 line) unit tests _just_ to test that you can instantiate the objects and catch basic type errors. If it's a web app, a simple script that starts a local instance and then make sures that retrieving "GET /" returns "200 OK" is again a huge improvement over _nothing_.
Overall, my/tlb's recommendation remains: be in a position where good programmers can offer you good feedback and where you're pushed to improving your own capacity.
I've worked for two companies in the past year and a half, both with teams of ~5-10 developers, and nobody at either company was/is using any sort of automated tests. It's definitely frustrating -- not to mention lonely -- especially when you're immersed in a culture (hello HN) that's pimping a new test runner every two weeks.
I like testing for one and a half reasons: to capture the software requirements, and to change the software easily when those requirements change. If you've got one test, that's better than zero.
You don't have to set up your own Jenkins server -- Travis CI should do the trick nicely, and it's super easy to set up (although I know you're not supposed to say that kind of thing).
Here's a thought: Could you persuade the CTO to let you add the tests as a submodule to the project repo?
The attitude about cloud services is more understandable, though inconvenient. However, I think you may be laboring under a misapprehension: You don't need to have a CI server to run tests automatically, you can have a test suite running locally and trigger it with a pre-commit hook (so you can't actually commit if a test fails).
Not with that attitude, you're not :)