diff --git a/packages/frontend/docs/releasing.md b/packages/frontend/docs/releasing.md
new file mode 100644
index 00000000..c0ab13e2
--- /dev/null
+++ b/packages/frontend/docs/releasing.md
@@ -0,0 +1,38 @@
+# Guidelines for New Releases
+
+Let's assume we have a stable `dev` branch with all the features, bug fixes
+and any other changes that we may want to add for an upcoming new release.
+
+We may now follow these steps:
+
+1. Pick a version number. If current version is `vX.Y.Z`, next version will be:
+
+-   `X.Y.Z+1`: if it includes bug fixes, chores or other minor changes. (AKA patch release).
+-   `X.Y+1.Z`: if it includes new features. (AKA minor release).
+-   `X+1.Y.Z`: if it's a complete new version, with either major functionality
+    changes, a new API or a complete new UI design (AKA major release).
+
+1. Bump the version number in [`package.json`](./package.json), commit and open
+   a PR to `dev`. Make sure the PR is squashed as a single commit with the
+   format `[chore] version bump - vX.Y.Z"` (something like `vX.Y.Z` is fine too).
+
+1. Open a new PR to merge `dev` into `main`. Wait for the basic tests to run.
+   Ask another dev to review this PR.
+
+1. If the tests are okay and the PR is approved, **make sure it is merged using a merge commit**,
+   DO NOT SQUASH.
+
+1. Immediately after merging into `main`, go to [release](https://github.com/AlphadayHQ/frontend/releases)
+   and click on "draft a new release". Make sure the release targets `main` and create a new tag called `vX.Y.Z`.
+   Include autogenerated logs. Mark is a pre-release if that is the case.
+
+1. At this point, a Github action will already rollout an **staging** release.
+
+1. **Deploy to Production**: If the staging release is stable and QA-approved,
+   we should now be able to rollout a new production release. Production deployments
+   are manually triggered from the [actions](https://github.com/AlphadayHQ/frontend/actions)
+   menu in Github's UI (see _Deploy to Production_). **Make sure you choose the `main` branch**.
+
+1. If the staging version has bugs, we'll add bug fixes in the `dev` branch, and version `vX.Y.Z` will be skipped in production. We'll instead move back to step `2.` and try a new hot-fix release `vX.Y.Z+1` including the bug fixes found in staging.
+
+1. If the production version has bugs and a hotfix is needed, we add the bug fixes to a hot-fix branch that stems from the `main` branch. The version of this branch is bumped to `vX.Y.Z-hotfix` and then released to production. Once the hotfix is released, The bug fixes should also be added to the `main` branch
\ No newline at end of file