diff --git a/docs/en/02_Developer_Guides/05_Extending/00_Modules.md b/docs/en/02_Developer_Guides/05_Extending/00_Modules.md
index 368e2d597..0861a783b 100644
--- a/docs/en/02_Developer_Guides/05_Extending/00_Modules.md
+++ b/docs/en/02_Developer_Guides/05_Extending/00_Modules.md
@@ -14,20 +14,6 @@ Modules are [Composer packages](https://getcomposer.org/), and are placed in the
 These packages need to contain either a toplevel `_config` directory or `_config.php` file,
 as well as a special `type` in their `composer.json` file ([example](https://github.com/silverstripe/silverstripe-module/blob/4/composer.json)).
 
-```
-app/
-|
-+-- _config/
-+-- src/
-+-- ..
-|
-vendor/my_vendor/my_module/
-|
-+-- _config/
-+-- composer.json
-+-- ...
-```
-
 Like with any Composer package, we recommend declaring your PHP classes through
 [PSR autoloading](https://getcomposer.org/doc/01-basic-usage.md#autoloading).
 Silverstripe CMS will automatically discover templates and configuration settings
@@ -77,9 +63,104 @@ or share your code with the community. Silverstripe CMS already
 has certain modules included, for example the `cms` module and core functionality such as commenting and spam protection
 are also abstracted into modules allowing developers the freedom to choose what they want.
 
+### Create a new directory
+
 The easiest way to get started is our [Module Skeleton](https://github.com/silverstripe/silverstripe-module).
-In case you want to share your creation with the community,
-read more about [publishing a module](how_tos/publish_a_module).
+
+First, create a new directory named after your intended module in your main project. It should sit alongside the other modules
+such as *silverstripe/framework* and *silverstripe/cms* and use it for the module development:
+
+`mkdir /vendor/my_vendor/nice_feature`
+
+Then clone the Module Skeleton to get a headstart with the module files:
+
+```bash
+cd /vendor/my_vendor/nice_feature
+git clone git@github.com:silverstripe/silverstripe-module.git .
+```
+
+### Allow your module to be importable by composer
+
+You need to set your module up to be importable via composer. For this, edit the new `composer.json` file in the root of
+your module. Here is an example for a module that builds on the functionality provided by the `blog` main module (hence the
+requirement):
+
+```json
+{
+	"name": "my_vendor/nice_feature",
+	"description": "Short module description",
+	"type": "silverstripe-vendormodule",
+	"require": {
+		"silverstripe/cms": "^4.0",
+		"silverstripe/framework": "^4.0",
+		"silverstripe/blog": "^4@dev"
+	}
+}
+```
+
+After your module is running and tested, you can publish it. Since your module is a self-contained piece of software, it
+will constitute a project in itself. The below assumes you are using GitHub and have already created a new GitHub repository for this module.
+
+Push your module upstream to the empty repository just created:
+
+```bash
+	git init
+	git add -A
+	git commit -m 'first commit'
+	git remote add origin git@github.com:my_vendor/nice_feature.git
+	git push -u origin master
+```
+
+Once the module is pushed to the repository you should see the code on GitHub. From now on it will be available for
+others to clone, as long as they have access (see the note below though: private modules are not deployable).
+
+### Including a private module in your project
+
+Including public or private repositories that are not indexed on **Packagist** is different from simply using the `composer require silverstripe/blog` command. We will need to point *composer* to specific URLs. Background information can be found at
+[Working with project forks and unreleased
+modules](../../getting_started/composer/#working-with-project-forks-and-unreleased-modules).
+
+For our *nice_module* example module we have just pushed upstream and can add the following lines to your `composer.json` file in the root directory of your main project.
+
+```json
+	"repositories": [
+		{
+			"type": "vcs",
+			"url": "git@github.com:my_vendor/nice_feature.git",
+		}
+	]
+```
+
+This will add the repository to the list of URLs composer checks when updating the project dependencies. Hence you can
+now include the following requirement in the same `composer.json`:
+
+```
+	"require": {
+		...
+		"my_vendor.nice_feature": "*"
+	}
+```
+
+Add the module directory name (`nice_feature/`) to `.gitignore` - we will rely on *composer* to update the dependencies so
+we don't need to version-control it through the master repository.
+
+Run `composer update` to pull the module in and update all other dependencies as well. You can also update just this one
+module by calling `composer update my_vendor/nice_feature`.
+
+If you get cryptic composer errors it's worth checking that your module code is fully pushed. This is because composer
+can only access the code you have actually pushed to the upstream repository and it may be trying to use the stale
+versions of the files. Also, update composer regularly (`composer self-update`). You can also try deleting Composer
+cache: `rm -fr ~/.composer/cache`.
+
+Finally, commit the the modified `composer.json`, `composer.lock`  and `.gitignore` files to the repository. The
+`composer.lock` serves as a snapshot marker for the dependencies - other developers will be able to `composer install`
+exactly the version of the modules you have used in your project, as well as the correct version will be used for the
+deployment. Some additional information is available in the [Deploying projects with
+composer](https://docs.silverstripe.org/en/4/getting_started/composer/#deploying-projects-with-composer).
+
+### Open-sourcing your creation for the community to use
+
+In case you want to share your creation with the community, read more about [publishing a module](how_tos/publish_a_module).
 
 ## Module Standard