Look at all of them, then throw them away. Start with a lexer, a parser (pretty easy), the AST is already done, then it's all about the eval loop. All you need is sit down until you understand Lisp's metacircular evaluator (less than 50 lines or code), which is all you need to implement eval.
Do you imagine it to be especially hard or impossible to replace an interpreter with a compiler instead of implementing a compiler from scratch? It makes it harder to have decided on the language design rather than inventing it in parallel?
From an interpreted Lisp system to a compiler it's mostly a slog of studying compilers and assembly (or machine code) and possibly translating the interpreter, which you can use to bootstrap the compiler implementation if you'd like.
It's especially hard when you don't have semantics for your language outside of what your interpreter does. Then the semantics of the language in the book are plain bad: there is only dynamic scoping (oh, and the book often has plain misinformation - the provided definition of "lexical scoping" is wrong), and setting a local variable only affects the innermost LET if you nest environments, since the interpreter deep-copies environments (as it does with everything, to cope with lack of GC).
The book also uses something more like fexprs than macros, which I don't have an opinion _outside of this book_ on with regards to language UX, but fexprs are generally harder to compile. That is in part because they control if/when their arguments are evaluated, but the fexpr-alike things here do not (instead "Q-expressions" delay evaluation like QUOTE). You still would want to do something about calls to EVAL though. The fexpr system _in this book_ also does have bad UX: it only incidentally works with dynamic binding (Shutt's lexically scoped fexprs explicitly pass the environment around) and it also leaks every variable binding from the fexpr function into what it evaluates.
The book also just doesn't cover compilers, so you're doing that slog on your own.
