I've done the following before, it works well at the beginning of a project:

1. Define a core, end to end test case (the basic thing that your product or piece of code does)
2. Ask every dev to test this before merge
3. 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
4. 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

What is your language? I'm using PHP and therefor trying to follow PS2 strictly. At least the code is well organised then.

If anything related to websites, a bare minimum of tests should be if your endpoints (URLs) are working and giving a response code 200 or whatever that is expected.

The best alternative to tests is hoping that you're not going to be working on this anymore in 5 years, I guess.

• Code reviews.
• Maybe a linter can catch some of the easier bugs.
• Good use of type system may be even better than tests, but takes quite some practise and time, so maybe you can't afford that either.
• Testing manually is cheaper short-term - it's usually faster to test manually once than it is to write a test. The problem is that testing the thing again for every release isn't.

in short? test manually.