I've done the following before, it works well at the beginning of a project:
- Define a core, end to end test case (the basic thing that your product or piece of code does)
- Ask every dev to test this before merge
- Write down 5-10 test cases (think of this as your release criteria) and make it available to your team (or yourself) as a wiki, google doc or similar
- Whoever owns releasing the software (whatever a release means for you, this could be a merge to master, pushing a binary somewhere else, etc...) should go through those cases manually before doing it.
In my opinion, having tests or not is all a matter of how much risk you're willing to take. If you don't have customers, and you're only building this for yourself, the risk of a regression is low. I do find it useful to write one or two end-to-end cases early on to save me from having to test everything manually all the time, but your level of tolerance to repetitive tasks might be higher than mine :P