diff --git a/.eslintrc.js b/.eslintrc.js
index 6f44c8b18f3..3017f94a396 100644
--- a/.eslintrc.js
+++ b/.eslintrc.js
@@ -11,7 +11,6 @@ module.exports = {
 		// window.guardian is our global config/settings object
 		'id-denylist': ['error', 'guardian'],
 	},
-	ignorePatterns: ['javascripts.flow.archive'],
 	overrides: [
 		{
 			files: ['*.ts', '*.tsx'],
@@ -35,13 +34,13 @@ module.exports = {
 				],
 			},
 		},
-        {
-            files: ['*.spec.ts'],
-            rules: {
-              // This rule erroneously flags up instances where you expect(obj.fn).toHaveBeenCalled
-              // Enabled for test files only
-              '@typescript-eslint/unbound-method': 'off',
-            },
-          },
+		{
+			files: ['*.spec.ts'],
+			rules: {
+				// This rule erroneously flags up instances where you expect(obj.fn).toHaveBeenCalled
+				// Enabled for test files only
+				'@typescript-eslint/unbound-method': 'off',
+			},
+		},
 	],
 };
diff --git a/.vscode/extensions.json b/.vscode/extensions.json
index 25083f88586..632b76009ce 100644
--- a/.vscode/extensions.json
+++ b/.vscode/extensions.json
@@ -6,8 +6,7 @@
 	"recommendations": [
         "dbaeumer.vscode-eslint",
         "editorconfig.editorconfig",
-        "esbenp.prettier-vscode",
-        "flowtype.flow-for-vscode"
+        "esbenp.prettier-vscode"
 	],
 	// List of extensions recommended by VS Code that should not be recommended for users of this workspace.
 	"unwantedRecommendations": [
diff --git a/docs/01-start-here/04-troubleshooting.md b/docs/01-start-here/04-troubleshooting.md
index e3687dbfa60..dc0a1e12cd5 100644
--- a/docs/01-start-here/04-troubleshooting.md
+++ b/docs/01-start-here/04-troubleshooting.md
@@ -30,7 +30,7 @@ If this doesn't work, you can clean everything with `cleanAll` in `root`.
 
 If you're still seeing errors, try clearing out all build and `.gitignore`d folders, which includes `target` folders:
 
-> **Note:** This will wipe *everything*, not just `target/` (built) folders - including `node_modules/` 
+> **Note:** This will wipe *everything*, not just `target/` (built) folders - including `node_modules/`
 
 ```
 git clean -fxd
@@ -67,17 +67,6 @@ Run `make reinstall` to resolve.
 ### Accidentally ran `npm install` or `yarn install`
 Run `make reinstall` to resolve.
 
-### Run Flowtype checks takes forever
-The Flowtype checks happen automatically when you push your branch, assuming you have made JavaScript changes.
-
-Flow can sometimes take a long time to run. The first time you run Flowtype checks, Flow starts up a Flow server which is a slow process. If you think Flow is hanging ([a known bug](https://github.com/facebook/flow/issues/3528)), you can try stopping the Flow server by running:
-
-```bash
-$ yarn flow stop
-```
-
-Next time you push your branch or manually run the Flow checks, a new Flow server will be started.
-
 ### Global install permissions errors
 The script installs global npm packages without sudo. If you get npm permission errors, follow the guide to using npm without sudo [here](https://github.com/sindresorhus/guides/blob/master/npm-global-without-sudo.md).
 
diff --git a/docs/01-start-here/05-development-tips.md b/docs/01-start-here/05-development-tips.md
index bfdcd60e3f9..64413a92c3d 100644
--- a/docs/01-start-here/05-development-tips.md
+++ b/docs/01-start-here/05-development-tips.md
@@ -24,10 +24,9 @@ make test
 make fix
 make validate
 ```
-These will fix up the linting issues and check all the flow types to make sure you won't have any issue
-trying to push or with the simple parts of the build.
+These will fix the linting issues to make sure you won't have any issue trying to push or with the simple parts of the build.
 
-If you have already committed you can use `make fix-commits` to verify & fix your commited code. It's 
+If you have already committed you can use `make fix-commits` to verify & fix your commited code. It's
 faster than `make fix` but you will need to amend your previous commits to get a clean history.
 
 If you are wondering what other options make has, you can simply type `make` at the comment line.
@@ -53,16 +52,16 @@ Ensure the Transport is Socket, the Debugger mode is Attach, and the port is set
 Start a new Debug session, and your breakpoints should be active.
 
 ### Developing in IntelliJ
- 
+
 To use the sbt shell, you should use the same configuration for the JVM as in the [custom sbt script](../../sbt).
-As an example of how to achieve this, the picture below demonstrates increasing the maximum heap size to 8000 and 
+As an example of how to achieve this, the picture below demonstrates increasing the maximum heap size to 8000 and
 providing the `APP_SECRET` as a Java system property.
 
 ![sbt_options](https://user-images.githubusercontent.com/4085817/67011346-4ce99980-f0e7-11e9-81fd-f1208e672800.png)
 
 Being able to use sbt shell has a number of advantages:
 - IntelliJ can be [configured to use sbt shell for build and import](https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000117230-Sbt-shell-for-build-an-import);
-- and (perhaps more pertinently), by clicking on the debug icon (pictured below) you can debug the Scala application(s) 
+- and (perhaps more pertinently), by clicking on the debug icon (pictured below) you can debug the Scala application(s)
 without having to configure the debugger yourself:
 
   ![debug_icon](https://user-images.githubusercontent.com/4085817/67011976-7bb43f80-f0e8-11e9-93fd-052ede190e34.png)