review feedback applied

Author: jyecusch

src/pages/concepts/infrastructure-from-code.mdx

@@ -21,7 +21,7 @@ Sometimes it's easier to explain IfC by exploring the benefits.
 
 ## Rapid Development
 
-Nitric significantly reduces or removes cloud-specific code. For example, accessing a file in a cloud storage bucket with nitric is just a few lines of code, while the equivalent code using cloud provider SDKs is much more verbose and error prone:
+Nitric significantly reduces or removes cloud-specific code. For example, accessing a file in a cloud storage bucket with Nitric is just a few lines of code, while the equivalent code using cloud provider SDKs is much more verbose and error prone:
 
 <CodeGroup>
 
@@ -100,7 +100,7 @@ provider: your_namespace/[email protected]
 
 <Note>
   The runtime code for cloud services like SNS still exists, it's just isolated
-  to an independent module. It could be from a [nitric
+  to an independent module. It could be from a [Nitric
   provider](https://github.com/nitrictech/nitric/blob/main/cloud/aws/runtime/topic/sns.go)
   or [something custom](/reference/providers/custom/building-custom-provider)
   built by you or an independent team, such as platform engineers or DevOps

src/pages/index.mdx

@@ -41,7 +41,7 @@ services:
     start: npm run dev:services $SERVICE_PATH
 ```
 
-You might have one service that handles everything, or a service for each route. It's up to you. Every matched services becomes a container, so you can scale them independently.
+You might have one service that handles everything, or a service for each route. It's up to you. Every matched service becomes a container, allowing them run and scale independently.
 
 ---
 
@@ -173,8 +173,8 @@ So, a project structure might look something like this:
 example/
 ├── nitric.yaml
 ├── services/
-│   └── orders.ts
-│   └── users.ts
+│   └── orders.js
+│   └── users.js
 └── package.json
 ```