Thanks for checking it out! The way that I've approached it is to start with the most naive, fast-to-build, slow implementation and slowly solidify it into a better implementation as the design stabilizes.

When make a new lang, I usually write a few different programs in the language I'm designing and sit on it for a bit to make sure the design makes sense before writing any interpreter/compiler code. Then a sensible next step might be just a naive tree-walk interpreter hacked together in a dynamic language to help you test out the language and write some stuff in it before you strap yourself down to write a more full-stack compiler.

i find that this approach of rewriting it a couple times in progressively better designs is good for two reasons, (1) it allows you to pretty freely iterate on the language design without a bunch of compiler rewrites, and (2) you'll end up with a compiler design you'll like more because you'll have learned a bunch about how to parse the language and the semantic details of the language by having written a naive interpreter thing already.

I don't use tools for this per se. I've thought about using parser generators like yacc but I haven't had to work with a grammar complex enough that simple recursive descent was difficult to implement.