It’s interesting to see it all laid out like this because I suspect many of us don’t think about a lot of those steps!
My workflow would have a REPL up and running much sooner – before I wrote any Clojure code! – and I’d be leveraging the tools.deps.alpha branch for add-lib so I can add dependencies to the running REPL without restarting.
I’d skip the CRUD namespaces I expect, and work directly with next.jdbc, and only refactor into separate namespaces later once I had a better sense of the shape of my code, and only then if I felt it was worth it.
I’d probably evolve the DB schema with migrations over time rather than trying to nail it down up front – I might even avoid a DB and just use atoms for data storage until more of the app has evolved, and then develop the schema from that instead (i.e., instead of starting with the DB).
If my code’s on GitHub, I’d leverage Actions for CI, from the get-go I expect.
If it’s a small app (as you say), I’d try to do as little “up front” as possible, and avoid complexity wherever possible (so I wouldn’t use an application server, I’d just use the embedded Jetty server).
I’d want to get a skeleton app up and running early on, without any front end polish, so I could get that in the hands of stakeholders, to iterate the app with them.