diff --git a/board/common/rootfs/etc/finit.conf b/board/common/rootfs/etc/finit.conf
index afc0b007..00d0af6b 100644
--- a/board/common/rootfs/etc/finit.conf
+++ b/board/common/rootfs/etc/finit.conf
@@ -1,2 +1 @@
 set COLORTERM=yes
-runparts /cfg/start.d
diff --git a/doc/container.md b/doc/container.md
index d34ad868..c0cad866 100644
--- a/doc/container.md
+++ b/doc/container.md
@@ -153,7 +153,7 @@ Automating start/stop at boot/reboot is documented in the next section.
 ### Hybrid Mode
 
 Since container setup and configuration is not modeled in YANG yet, we
-use the Infix *Hybrid mode*, also described in the README.
+use the Infix *Hybrid mode*, described in [Infix Variants](variant.md).
 
 To start containers in *Hybrid Mode*, provided the images have been
 downloaded with `podman pull docker://troglobit/buildroot:latest` and
diff --git a/doc/developers-guide.md b/doc/developers-guide.md
index 1c45fb83..4b47031d 100644
--- a/doc/developers-guide.md
+++ b/doc/developers-guide.md
@@ -14,6 +14,26 @@ $ cd infix/
 $ git submodule update --init
 ```
 
+### Customer Builds
+
+Customer builds add product specific device trees, more OSS packages,
+e.g., Frr and podman, and sometimes integrates proprietary software.
+What's *important to remember*, however, is that they are all made by
+setting up Infix as a GIT submodule, similar to how Infix set up a GIT
+submodule for Buildroot.
+
+So, in addition to using the customer's specific defconfig(s), one must
+also make sure to update *all submodules*, otherwise you will likely end
+up with a broken build.
+
+```bash
+$ ...
+$ git submodule update --init --recursive
+                              ~~~~~~~~~~~
+```
+
+Other caveats should be documented in the customer specific trees.
+
 
 Building
 --------
@@ -59,10 +79,15 @@ and then use GitHub to create a *Pull Reqeuest*.
 
 For this to work as painlessly as possible:
 
-  1. Fork Infix to your own user
+  1. Fork Infix to your own user or organization[^1]
   2. Fork all the Infix submodules, e.g., `buildroot` to your own user
+     or organization as well
   3. Clone your fork of Infix to your laptop/workstation
 
+If you use a GitHub organization you get the added benefit of having
+local peer reviews of changes before making a pull request to the
+upstream Infix repository.
+
 ```bash
 $ cd ~/Projects
 $ git clone https://github.com/YOUR_USER_NAME/infix.git
@@ -74,5 +99,11 @@ $ git submodule update --init
 > may have to synchronize your forks as well.  GitHub have a `Sync fork`
 > button in the GUI for your fork for this purpose.
 
+[^1]: Organizations should make sure to lock the `main` (or `master`)
+    branch of their clones to ensure members do not accidentally merge
+    changes there.  Keeping these branches in sync with upstream Infix
+    is highly recommended as a baseline and reference.  For integration
+	of local changes another company-specific branch can be used instead.
+
 [1]: https://buildroot.org/downloads/manual/manual.html
 [2]: https://github.com/wkz/qeneth
diff --git a/doc/variant.md b/doc/variant.md
index ddcecffa..da89fd07 100644
--- a/doc/variant.md
+++ b/doc/variant.md
@@ -63,6 +63,15 @@ To work around that we use the [run-parts(8)][] feature of the system,
 available in some customer specific images.  The system runs any user
 scripts in `/cfg/start.d` before leaving runlevel S (bootstrap).
 
+> **Note:** a vanilla Infix build does not support Hybrid Mode out of
+> the box.  You can enable it, and build your own images by adding the
+> following line to `board/common/rootfs/etc/finit.conf`:
+>
+>         runparts /cfg/start.d
+>
+> See the [Developer's Guide](developers-guide.md) for a build HowTo.
+
+
 ### Starting OSPF
 
 For example, the following starts OSPF: