Adds a few more links and formatting

www/_blog/2021-11-30-supabase-studio.mdx

@@ -21,12 +21,12 @@ and [Self-Hosting](https://supabase.com/docs/guides/hosting/overview).
 
 ## Background
 
-Let's get the obvious question out of the way first - why wasn't it already open source?
+Let's get the obvious question out of the way - why wasn't it already open source?
 
-When Ant and I started Supabase the code-base was one large monorepo which contained everything from the dashboard to cloud infrastructure code to experimental code. 
-This is our our preferred strategy - we like to keep all code in one place so that we have a single source of truth and tightly coupled CI workflows.
+When Ant and I started Supabase the codebase was one large monorepo which contained everything from the dashboard to cloud infrastructure code to experimental code. 
+This is our our preferred development setup - we like to keep all code in one place so that we have a single source of truth and tightly coupled CI workflows.
 
-The original Dashboard really wasn't much except a couple of button which allowed our Alpha users to start and stop a Supabase project.
+The original Dashboard really wasn't much except a couple of button which allowed our Alpha users to start and stop a Supabase project - back then only a PostgreSQL connection string.
 
 Then time went on, and we started gaining traction - a lot faster than expected. 
 The nice thing about building for developers is that they are very vocal about the features they want to see next. 
@@ -38,48 +38,51 @@ But as feature requests kept rolling in it became a Sisyphean task to maintain s
 
 After the last Launch Week, we decided to prioritize the Studio.
 
-## Approaches for managing shared code-bases
+## Approaches for managing shared codebases
 
-We investigated a few different approaches used in the open source world. There are three popular strategies that we found among OSS projects and some of our YC alum:
+We investigated a few different approaches used in the open source world. There are three popular strategies that we found amongst OSS projects and some of our YC alum:
 
 - Maintain separate code bases. Pluck changes from one to another.
-- Keep two repos in sync using some mixture of git submodules or a tool like `[copycat](https://github.com/atomix/copycat)`
-- Use the same code-base, abstracting platform-specific code behind an API and feature flags
+- Keep two repos in sync using some mixture of git submodules or a tool like [`copycat`](https://github.com/atomix/copycat)
+- Use the same codebase, abstracting platform-specific code behind an API and feature flags.
 
 Our frontend team experimented with the first two approaches where they plucked (injected, merged, and wrangled) code for our Platform. 
 Time-to-production become a lot slower, an unacceptable outcome at Supabase. 
 
-Eventually we decided to open source all the frontend code, so the code for both the Platform and Self Hosted is completely public, sharing the same code-base. 
+Eventually we decided to open source all the frontend code, a shared codebase for both the Platform and Self Hosting. 
 
-- Special shout out
-    
-    Sentry do a fantastic job of [documenting their strategy](https://develop.sentry.dev/sentry-vs-getsentry/) for managing a shared code-base and served as a great model for Supabase. 
+<details>
+<summary>
+Special shout out
+</summary>
+Sentry do a fantastic job of [documenting their strategy](https://develop.sentry.dev/sentry-vs-getsentry/) for managing a shared codebase and served as a great model for Supabase. 
+</details>
     
 
 ## Build in public
 
-For the past week, the dashboard you've been using on the Platform has been deployed from our [main repository](https://github.com/supabase/supabase), 
-the one you might also be using for Self-Hosting. 
+For the past week, the dashboard you've been using on the Platform has been deployed from our [main repository](https://github.com/supabase/supabase/tree/master/studio). 
 
-This fits one of our core philosophies at Supabase: do less. Less code to manage means less bugs. Fewer code-bases means faster shipping.
+This fits one of our core philosophies at Supabase: do less. Less code to manage means less bugs. Fewer codebases means faster shipping.
 
 It also fits the development philosophy of every other part of Supabase: building in public, "warts and all".
 
 This is a huge step forward for the community. Supabase users can now spot a bug, fix it in the open source repository, 
-and have it shipped to both the Platform and Self-Hosted environments - all in a single day.
+and have it shipped to both the Platform and Self-Hosted environments - all in a few hours.
 
 ## Technical details
 
-Let's jump into some of the technical details.
+Let's jump into some of the technical implemetation for Supabase Studio.
 
 ### Tech stack
 
-Studio is built Javascript application with a few key pieces.
+Studio is a Javascript application with a few key pieces of technology:
 
 - [Next.js](https://nextjs.org/) - A frontend Javascript framework built with React.
 - [Tailwind](https://tailwindcss.com/) - A utility-first CSS framework.
 - [Supabase UI](https://ui.supabase.io/) - Our own component library. 
 - [MobX](https://www.mobxjs.com/) - A state management library.
+- A host of other [useful libraries](https://github.com/supabase/supabase/blob/master/studio/package.json), including [Radix UI](https://www.radix-ui.com), [Lottiefiles](https://lottiefiles.com/), [react-grid-layout](https://github.com/react-grid-layout/react-grid-layout), and [zxcvbn](https://github.com/dropbox/zxcvbn).
 
 ### What's included
 
@@ -88,17 +91,13 @@ It is not intended for managing the deployment and administration of projects -
 
 The features exposed on Studio for existing deployments are limited to those which manage your database: 
 
-- Table & SQL editors
-    - Saved queries are unavailable
-- Database management
-    - Policies, roles, extensions, replication
-- API documentation
-- Settings
-    - Project settings are managed outside of the Dashboard. If you use docker-compose, you should manage the settings in your docker-compose file. If you're deploying Supabase to your own cloud, you should store your secrets and env vars in a vault or secrets manager.
+- Table & SQL editors. (Saved queries are unavailable for now)
+- Database management: Policies, roles, extensions, replication.
+- API documentation.
 
-Over time we'll migrate a lot more of the code-base into the self-hosted Dashboard, this was as much as we could migrate for this Launch Week!
+Over time we'll expose a lot more of the codebase in the self-hosted Dashboard, this was as much as we could do for this Launch Week!
 
 ## How to contribute?
 
-Check out the full instructions in our [Studio Readme]().
+Check out the full instructions in our [Studio Readme](https://github.com/supabase/supabase/tree/master/studio).