While I was a Debian user, my preferred method of installing new systems was roughly this:
This could be a smooth process, but debootstrap is a spaceship. It both depends on a lot of script and binaries residing the host system (grml in my case) _and_ wants to chroot into the freshly installed system.
The former property is annoying because I tend to have an old grml with old debootstrap scripts so I can install only old Debian systems (which then have to be dist-upgraded a few times then switched over to Devuan). I tried to upgrade debootstrap only on the host system, but that's pretty much impossible because of the extensive dependencies.
Conjlinux solves this by making sure conjbootstrap dependencies and the install_pre/install_post dependencies of the few packages that it needs to install are absolutely minimal that any reasonable host system would have by default. Things like POSIX shell, POSIX awk, coreutils, tar, xz.
The second property is real annoying because it forces me to have the same host and target arch. It's a reasonable requirement if I want to chroot into the target on the host during installation. But I most often wouldn't need to: if debootstrap set up some default root password and could set up the kernel and boot loader without having to chroot (initramfs doesn't help with that!), I could just move the resulting root onto the target hardware and boot it there and go on with the rest of the steps self-hosted already. The typical use case: installing a system on an sdcard for an SBC (Orange PI, raspberry PI). Host arch is x86_64, target arch is some arm.
This problem is solved by conjbootstrap not attempting to chroot. Instead it installs a few packages "manually" and leaves a digest for the package manager that will be first run only when the target system is already self-hosted.
As a bonus not having to chroot means conjbootstrap doesn't necessarily need to be run as root: it can use fakeroot to pack up the target system in a tarball with all files and permissions properly set.