diff --git a/docs/homepage.md b/docs/homepage.md
new file mode 100644
index 000000000..6690087a4
--- /dev/null
+++ b/docs/homepage.md
@@ -0,0 +1,45 @@
+# Homepage
+
+## Popular Links
+
+Popular links are the links that are present on GOV.UK under _'Popular on GOV.UK'_.
+These links are maintained through this Mainstream Publisher app.
+
+### How to edit popular links
+
+Popular links can be accessed and edited via the 'Homepage' link on Signon, for this we need the 'homepage_editor' permission inside the Mainstream Publisher app.
+
+#### More context on homepage permissions
+
+Signon by nature expects each link on the dashboard to link to a separate app, whereas the popular links editor lives inside the Mainstream Publisher app. The Homepage link on signon integration was generated by running the below command in signon kubernetes (refer to the [signon usage documentation](https://docs.publishing.service.gov.uk/repos/signon/usage.html) for details).
+
+```shell
+rake applications:create name=Homepage description="Responsible for creating contents for homepage" \
+     home_uri="https://publisher.integration.publishing.service.gov.uk/homepage/popular-links" \
+     redirect_uri="https://publisher.integration.publishing.service.gov.uk/homepage/popular-links/auth/gds/callback"
+```
+
+We do not store the secrets generated by this command and just rely on the secrets already configured for Mainstream publisher. This makes Homepage appear as an app in signon, but it's really just a link to a page in Mainstream Publisher. This also means all the permissions related to the Homepage "app" can only be managed through Mainstream publisher. Hence, in order to get access to the Homepage "app" we need the `homepage_editor` permission for the user in Mainstream Publisher.
+
+### Questions
+
+#### Which schema in publishing api does popular links use?
+
+link_collection
+
+#### Why popular links as a separate content item instead of moving the whole of homepage to publisher?
+
+Currently our use case is only to allow publishing of popular links and not any other content on the homepage, though in the future we might want to allow other content on the homepage to be published via Mainstream Publisher. Implementation-wise, we have investigated and understood how to allow publishing of popular link as a separate content item and link it to the homepage, and we think it is a simple approach to take at this point in time. If we want to allow other content items on the homepage to be publishable we can still create each of them as a separate content item and publish them separately, or move to a strategy of publishing homepage as a single content item. Though this strategy will require us to investigate more on how that can be done and understand the complexity and feasibility of it.
+
+#### Why is saving and publishing popular links a synchronous instead of asynchronous (via sidekiq)?
+
+There are a few reasons why we chose to keep it synchronous:
+    a. Allows us to give user real-time feedback in case of Publishing API failures.
+    b. Allows us to handle and rescue Publishing API errors in desired ways. eg: handle a 'Cannot publish already published' error to give the user appropriate feedback.
+    c. Unlike other editions which store their content-id in `Artefact`, popular links stores its content-id in `PopularLinksEdition`. This means that `publish_service.rb` (which is used to publish all editions) can't be used as-is to publish popular links because it reads edition's content-id from its artefact, which basically means we would have to introduce some logic to understand if the edition is a `PopularLinksEdition` or some other edition type, and based on that read content-id from the edition's artefact or from the `PopularLinksEdition` itself.
+
+#### Worth Reading 
+
+[PR with details of the schema changes](https://github.com/alphagov/publishing-api/pull/2750) made for popular links inside Publishing API.
+
+