diff --git a/README.md b/README.md
index 4984d45..ef803af 100644
--- a/README.md
+++ b/README.md
@@ -25,11 +25,11 @@ This website is built using [Docusaurus](https://docusaurus.io/), a modern stati
 
   - Clone repo `git clone https://github.com/inkdevhub/inkdevhub-docs`
   - Install dependencies by running `yarn` (`cd inkdevhub-docs`, `yarn` )
-  - `yarn start` - spin up a realtime website that updates dynamically based on your changes to the code.
+  - `yarn start` - spin up a real-time website that updates dynamically based on your changes to the code.
 
 ### New document / Modify existing document --> Submit a PR
   
-  -  Get latest version of docs locally
+  -  Get the latest version of docs locally
       - Make sure you’re on the main branch (`git checkout main`)
       - Pull the latest version of the docs (`git pull`)
       - Create a new branch (`git checkout -b feat/new-feature-name-here`)
diff --git a/docs/build/drink/index.md b/docs/build/drink/index.md
index a453f81..c9894be 100644
--- a/docs/build/drink/index.md
+++ b/docs/build/drink/index.md
@@ -2,7 +2,7 @@
 
 ## In brief
 
-DRink! is a toolbox for ink! developers that allows for a fully functional ink! contract development without any running node. It provides you with a unique, yet very powerful environment for interacting with contracts:
+DRink! is a toolbox for ink! developers that allows for a fully functional ink! contract-development without any running node. It provides you with a unique, yet very powerful environment for interacting with contracts:
 
 - deploy and call your contracts synchronously, **without any delays** related to block production or networking
 - gain access to **powerful features** that are not available with standard methods like **contract mocking, enhanced debugging and call tracing**
@@ -41,7 +41,7 @@ Before DRink!, you could have used ink!'s native test framework to execute eithe
 
 This paradigm is a peculiar compromise between the two other strategies. We give up the node layer (including networking, block production etc.), but we still have a fully functional runtime with attached storage. In other words, we keep bare blockchain state in-memory, and we can interact with it directly however we want.
 
-This way, we gain full control over the runtime, sacrificing real simulation of the blockchain environment. However, usually, this is higly beneficial for the development process, as it allows for a much faster feedback loop, assisted with better insights into execution externalities.
+This way, we gain full control over the runtime, sacrificing real simulation of the blockchain environment. However, usually, this is highly beneficial for the development process, as it allows for a much faster feedback loop, assisted with better insights into execution externalities.
 
 ---
 
diff --git a/docs/build/swanky/index.md b/docs/build/swanky/index.md
index 96837b7..93c92c1 100644
--- a/docs/build/swanky/index.md
+++ b/docs/build/swanky/index.md
@@ -18,7 +18,7 @@ Swanky Suite offers an extensible set of features, allowing developers to:
 - Provide Typescript based integration testing simulating interaction from the client-side;
 - Handle and manage network accounts;
 - Deploy smart contracts within the Polkadot ecosystem to networks that support `pallet-contracts`;
-- Make arbitrary calls to deployed smart contracts.
+- Make arbitrary calls to deploy smart contracts.
 
 ## Architecture Overview