diff --git a/docs/README.md b/docs/README.md
index 57f0f059b8..393df1c64d 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -2,7 +2,7 @@
 
 This project contains the out-of-source LibAFL documentation as a book.
 
-Here you can find tutorials, examples and detailed explanations.
+Here you can find tutorials, examples, and detailed explanations.
 
 For the API documentation instead, run `cargo doc` in the LibAFl root folder.
 
diff --git a/docs/src/introduction.md b/docs/src/introduction.md
index 94fb00b27e..c35050b44b 100644
--- a/docs/src/introduction.md
+++ b/docs/src/introduction.md
@@ -1,14 +1,29 @@
 # Introduction
 
-Fuzzers are important assets in the pockets of security researchers and even developers nowadays.
-A wide range of cool state-of-the-art tools like [AFL++](https://github.com/AFLplusplus/AFLplusplus), [libFuzzer](https://llvm.org/docs/LibFuzzer.html) or [honggfuzz](https://github.com/google/honggfuzz) are avaiable to users and they do their job in a very effective way.
+Fuzzers are important assets in the pockets of security researchers and developers alike.
+A wide range of cool state-of-the-art tools like [AFL++](https://github.com/AFLplusplus/AFLplusplus), [libFuzzer](https://llvm.org/docs/LibFuzzer.html) or [honggfuzz](https://github.com/google/honggfuzz) are available to users. They do their job in a very effective way, finding thousands of bugs.
 
-From the power user perspective, however, these tools are limited because not designed with the extensibility as first-class citizen.
-Usually, a fuzzer developer has to choose if fork one of these existing tools with the result of having a tons of fuzzers derived from others which are in any case incompatible with each other, or creating a new fuzzer from scratch, reinventing the wheel and usually giving up on features that are complex to reimplement.
+From the power user perspective, however, these tools are limited.
+Their design does not treat extensibility as a first-class citizen.
+Usually, a fuzzer developer can choose to either fork one of these existing tools, or to create a new fuzzer from scratch.
+In any case, researchers end up with tons of fuzzers, all of which are incompatible with each other.
+Their outstanding features can not just be combined for new projects.
+Instead, we keep reinventing the wheel and may completely miss out on features that are complex to reimplement.
 
-Here comes LibAFL, a library that IS NOT a fuzzer, but a collection of reusable pieces of fuzzers written in Rust.
-LibAFL helps you writing your own custom fuzzer, tailored for a specific target or for a particular instrumentation backend, without reinventing the wheel or forking an existing fuzzer.
+Here comes LibAFL, a library that IS NOT a fuzzer, but a collection of reusable pieces of fuzzers, written in Rust.
+LibAFL helps you develop your own custom fuzzer, tailored for your specific needs.
+Be it a specific target, a particular instrumentation backend, or a custom mutator, you can leverage existing bits and pieces to craft the fastest and most efficient fuzzer you can envision.
 
-## Why you should use LibAFL
+## Why LibAFL?
 
-TODO list here killer features (no_std, multi platform, scalability, ...)
+LibAFL gives you many of the benefits of an off-the-shelf fuzzer, while being completely customizable.
+Some highlight features currently include:
+- `multi platform`: LibAFL works pretty much anywhere you can find a Rust compiler for. We already used it on *Windows*, *Android*, *MacOS*, and *Linux*, on *x86_64*, *aarch64*, ...
+- `portable`: `LibAFL` can be built in `no_std` mode. This means it does not require a specific OS-dependent runtime to function. Define an allocator and a way to map pages, you should be good to inject LibAFL in obscure targets like embedded devices, hypervisors, or maybe even WebAssembly?
+- `adaptable`: Given year of experience fine-tuning *AFLplusplus* and our academic fuzzing background, we could incorporate recent fuzzing trends into LibAFL's deign and make it future-proof.
+To give an example, as opposed to old-skool fuzzers, a `BytesInput` is just one of the potential forms of inputs:
+feel free to use and mutate an Abstract Syntax Tree instead, for structured fuzzing.
+- `scalable`: As part of LibAFL, we developed `Low Level Message Passing`, `LLMP` for short, which allows LibAFL to scale almost linearly over cores. That is, if you chose to use this feature - it is your fuzzer, after all. Scaling to multiple machines over TCP is on the near road-map.
+- `fast`: We do everything we can at compiletime so that the runtime overhead is as minimal as it can get.
+- `bring your own target`: We support binary-only modes, like Frida-Mode with ASAN and CmpLog, as well as multiple compilation passes for sourced-based instrumentation, and of course supoprt custom instrumentation.
+- `usable`: This one is on you to decide. Dig right in!
\ No newline at end of file