diff --git a/src/main/jbake/content/documentation/arc42/src/09_design_decisions.adoc b/src/main/jbake/content/documentation/arc42/src/09_design_decisions.adoc
index fb36727..0f77a47 100644
--- a/src/main/jbake/content/documentation/arc42/src/09_design_decisions.adoc
+++ b/src/main/jbake/content/documentation/arc42/src/09_design_decisions.adoc
@@ -9,14 +9,14 @@ link:https://www.ozimmer.ch/practices/2023/04/03/ADRCreation.html[While writing
 ==== The problem
 There are a lot of different database systems out there for a lot of different use cases.
 
-As we don't want to have a discussion about what database to use for each new service we write, we want to decide on a default database that will cover most of our use cases.
+As we don't want to discuss what database to use for each new service we write, we want to decide on a default database that will cover most of our use cases.
 
 Note: We take into account that the chosen database system will probably not cover all our future use cases, which is why we will then decide on a different solution for specific cases if the need arises (which will then be documented as a separate ADR).
 
 [discrete]
 ==== Influencing Factors
 @Sebastian
-maybe I mix this up with Assumptions. Can you have a look on the assumptions, if parts of them are influencing factors?
+maybe I mix this up with Assumptions. Can you have a look at the assumptions, and if parts of them are influencing factors?
 
 [discrete]
 ==== Which quality goals are affected?
@@ -35,7 +35,7 @@ In both cases, we will finish our goals later, because of the additional time sp
 
 In most cases, we will have to deal with structured data. Also, our current team is well-versed in utilizing SQL databases.
 
-It's likely that we are in a situation where we need database transactions for implementing patterns like the transactional outbox pattern.
+We are likely in a situation where we need database transactions for implementing patterns like the transactional outbox pattern.
 
 We also do not expect that most of our databases will need to scale horizontally. If this assumption proves incorrect, we anticipate that moving to another database system will be manageable for us, given our adherence to the clean architecture style (or at the very least the DAO pattern).
 
@@ -51,7 +51,7 @@ Storing arbitrary JSON documents is also not an advantage (compared to PostgreSQ
  1. We primarily deal with structured data (see assumptions)
  1. PostgreSQL can also store JSON if needed
 
-We also have relatively limited expertise within the core team, especially when compared to PostgreSQL.
+We also have relatively limited expertise within the core team in using und operating MongoDB.
 
 [discrete]
 ==== PostgreSQL