diff --git a/shared-modules/mid-specialism-project/README.md b/shared-modules/mid-specialism-project/README.md
new file mode 100644
index 00000000..88cb8f16
--- /dev/null
+++ b/shared-modules/mid-specialism-project/README.md
@@ -0,0 +1,73 @@
+# Events Startup Project
+
+This is a standalone project where you will build a web application for an events startup. You will work individually to develop features for a ticketing platform that helps people view and buy tickets for events.
+
+## Project Learning Goals
+
+By the end of this module, you will be able to:
+
+- [ ] Apply your specialism knowledge and skills within a realistic work project
+- [ ] Practice running a full end-to-end project (e.g. planning with trello, through to deployment)
+- [ ] Transform requirements into functional working solutions
+- [ ] Successfully deploy complex services/applications
+- [ ] Overcome technical difficulties, find solutions independently, and know when to reach out and ask for help in a constructive manner
+- [ ] Plan a complex project and deliver it on time
+- [ ] Feel ready to run a similar process for the team final project
+
+## Scenario
+
+Welcome to your new job! We are an events startup, and you're here to help us develop our web app, which helps our users view and buy tickets for events.
+
+### Practical details
+
+- You'll work by yourself (sorry, you're the only developer we've hired!)
+- We have an existing app that you'll build on top of - it's basic so there's lots to do.
+- We have some strict requirements that you need to implement, but there is space for personalisation too.
+
+## Requirements
+
+Familiarise yourself well with the following documents to understand what is required to complete the project.
+
+Some of the requirements below are already working in the current version of the app, others will need to be implemented by you, and there are some suggestions of tasks where you can come up with additional ideas yourself.
+
+1. [Product Requirements Document (PRD)](./product-requirements-document.md)
+1. Technical Specification (spec)
+   1. [Frontend Course Spec](./frontend/technical-specification.md)
+   1. [Backend Course Spec](./backend/technical-specification.md)
+
+## How to organise your project
+
+Follow the requirements and practices from the [Intro to Agile](/courses/foundation/intro-to-agile/README.md) module.
+
+- [ ] Work as an individual to complete the project by yourself
+- [ ] Use Trello to organise your project tasks and visualise your progress
+- [ ] Define all of your tasks clearly using Trello cards
+- [ ] Create and prioritise your tasks at the start of each week, to have a clear idea of what will be required in that sprint
+- [ ] Submit a single pull request at the end of each sprint to be reviewed by your mentors.
+
+<!-- TODO: Consider setting up a Trello template with tags like sprint 1, sprint 2, or specific tasks to get them started -->
+
+## Project delivery
+
+These are the final deliverables that you should submit by the end-of-project deadline:
+
+### Frontend
+
+Links to the following:
+
+- [ ] Trello board
+- [ ] Initial design sketches
+- [ ] GitHub repo
+- [ ] Deployed web app
+
+### Backend
+
+Links to the following:
+
+- [ ] Trello board
+- [ ] GitHub repo
+- [ ] Database schema with ERD
+- [ ] Deployed API documentation
+- [ ] Deployed API service
+- [ ] Deployed database
+- [ ] Postman collection
diff --git a/shared-modules/mid-specialism-project/backend/technical-specification.md b/shared-modules/mid-specialism-project/backend/technical-specification.md
new file mode 100644
index 00000000..47ba93a5
--- /dev/null
+++ b/shared-modules/mid-specialism-project/backend/technical-specification.md
@@ -0,0 +1,21 @@
+# Technical Specification (Spec) Backend
+
+## Implementation Requirements
+
+You should use the technologies, skills, tools, and stack you've learned throughout the course. Here are some specific requirements that you must meet in your implementation:
+
+<!-- TODO: These requirements are by no means complete, just a couple of examples from each course curriculum to give a good example of how it should map to what we teach in the course -->
+
+- [ ] Database schema must be documented with an Entity-Relationship Diagram (ERD)
+- [ ] Database must use PostgreSQL
+- [ ] All database queries must use parameterized queries (no SQL injection vulnerabilities)
+
+## API
+
+We already have a fully functional API that you should use during your frontend development. You are welcome to make changes to it to change the data or add additional data. You can also add additional endpoints, if it is required for a new feature idea you have. However, the existing API functionality should remain in place and not break.
+
+We already have an API in place, but it is missing many features that you will be required to implement. You can find the API specification below, which describes what you will need to implement to complete the project.
+
+<!-- Part of the project is to design APIs, not only implement planned interfaces, so this will be a mix of documented and working enpoints, fully specced endpoints, as well as placeholders for endpoints that the trainee must design themselves e.g. in line with their data model -->
+
+<!-- TODO: Add or link to API contract specification - ultimately, this documentation should probably live inside the project skeletons, since the trainees will also own making changes to it as needed. -->
diff --git a/shared-modules/mid-specialism-project/backend/weekly-plan.md b/shared-modules/mid-specialism-project/backend/weekly-plan.md
new file mode 100644
index 00000000..9651e5fc
--- /dev/null
+++ b/shared-modules/mid-specialism-project/backend/weekly-plan.md
@@ -0,0 +1,25 @@
+# Weekly plan
+
+Here is a guideilne of the outcomes you should reach each week to stay on track.
+
+<!-- Guide for writing these:
+These weekly goals need to ensure two things:
+1. What trainees learn from the corresponding week in [database](/courses/backend/databases/README.md) and [node](/courses/backend/node/README.md) modules are practiced here in the right place
+2. All requirements/deliverables from the [project](../README.md) are well structured and ordered to ensure trainees can reach the end goals by week 5.
+
+For some context on how we ordered the milestones in the old meal sharing project, check [here](https://github.com/HackYourFuture-CPH/program/blob/main/contributing/proposals/mid-specialism-course-project.md#old-meal-sharing-content). Note that we have changed the structure of the corresponding modules too, but there is a big overlap in learning goals.
+ -->
+
+## Week 1 Sprint
+
+- [ ] (e.g. start with some planning tasks)
+
+## Week 2 Sprint
+
+## Week 3 Sprint
+
+## Week 4 Sprint
+
+## Week 5 Sprint
+
+- [ ] (e.g. end with some deploying tasks)
diff --git a/shared-modules/mid-specialism-project/frontend/technical-specification.md b/shared-modules/mid-specialism-project/frontend/technical-specification.md
new file mode 100644
index 00000000..7cca9623
--- /dev/null
+++ b/shared-modules/mid-specialism-project/frontend/technical-specification.md
@@ -0,0 +1,18 @@
+# Technical Specification (Spec) Frontend
+
+## Implementation Requirements
+
+You should use the technologies, skills, tools, and stack you've learned throughout the course. Here are some specific requirements that you must meet in your implementation:
+
+<!-- TODO: These requirements are by no means complete, just a couple of examples from each course curriculum to give a good example of how it should map to what we teach in the course -->
+
+- [ ] App must use React Router with distinct routes (e.g. event list, event detail, cart, orders)
+- [ ] Shared state (e.g. cart, user session) must use React Context
+
+## API
+
+We already have a fully functional API that you should use during your frontend development. You are welcome to make changes to it to change the data or add additional data. You can also add additional endpoints, if it is required for a new feature idea you have. However, the existing API functionality should remain in place and not break.
+
+<!-- For frontenders, the API will already be working and complete. For backenders, the API will also have some placeholders - part of the project is to design APIs, not only implement planned interfaces. -->
+
+<!-- TODO: Add or link to API contract specification - ultimately, this documentation should probably live inside the project skeletons, since the trainees will also own making changes to it as needed. -->
diff --git a/shared-modules/mid-specialism-project/frontend/weekly-plan.md b/shared-modules/mid-specialism-project/frontend/weekly-plan.md
new file mode 100644
index 00000000..13e94488
--- /dev/null
+++ b/shared-modules/mid-specialism-project/frontend/weekly-plan.md
@@ -0,0 +1,25 @@
+# Weekly plan
+
+Here is a guideilne of the outcomes you should reach each week to stay on track.
+
+<!-- Guide for writing these:
+These weekly goals need to ensure two things:
+1. What trainees learn from the corresponding week in [React](/courses/frontend/react/README.md) module are practiced here in the right place
+2. Requirements from the [PRD](../product-requirements-document.md) and [frontend spec](../frontend/technical-specification.md) are well structured and ordered to ensure trainees can reach the end goal by week 5.
+
+For some context on how we ordered the milestones in the old meal sharing project, check [here](https://github.com/HackYourFuture-CPH/program/blob/main/contributing/proposals/mid-specialism-course-project.md#old-meal-sharing-content). Note that we have changed the structure of the corresponding modules too, but there is a big overlap in learning goals.
+ -->
+
+## Week 1 Sprint
+
+- [ ] (e.g. start with some planning tasks)
+
+## Week 2 Sprint
+
+## Week 3 Sprint
+
+## Week 4 Sprint
+
+## Week 5 Sprint
+
+- [ ] (e.g. end with some deploying tasks)
diff --git a/shared-modules/mid-specialism-project/product-requirements-document.md b/shared-modules/mid-specialism-project/product-requirements-document.md
new file mode 100644
index 00000000..f65fad15
--- /dev/null
+++ b/shared-modules/mid-specialism-project/product-requirements-document.md
@@ -0,0 +1,48 @@
+# Product Requirements Document (PRD)
+
+These requirements describe the overall functionality of the app. Some of these are already implemented in the current app (marked with a check), the rest will need to be implemented by you.
+
+## 1. Browsing and Searching
+
+- [x] 1.1 Users can view a basic list of events
+- [ ] 1.2 Users can search and paginate through events
+- [ ] 1.3 Users can view individual event details (date, time, venue, description)
+- [ ] 1.4 Users can see ticket availability and pricing for an event
+
+## 2. Authentication
+
+- [x] 2.1 Unauthenticated users can browse events
+- [ ] 2.2 Authenticated users can see their account, previous orders etc.
+- [ ] 2.3 Unauthorized actions result in clear and actionable error to the user
+
+## 3. Shopping Cart
+
+- [x] 3.1 Users can add tickets to their shopping cart
+- [ ] 3.2 Users can select ticket quantity when adding to cart
+- [ ] 3.3 Items can be added, updated, or removed while in the cart
+- [ ] 3.4 Cart is saved across the session (and beyond the session, if authenticated)
+
+## 4. Checkout
+
+- [ ] 4.1 A user must be authenticated to checkout
+- [ ] 4.2 During checkout, the cart is finalized into an order, which can then no longer be changed
+
+## 5. History and Review
+
+- [ ] 5.1 Authenticated users can view a list of completed orders
+- [ ] 5.2 Authenticated users can view a specific order and its details
+- [ ] 5.3 Authenticated users can easily view and show their purchased tickets
+
+## 6. Error Handling and UX
+
+- [x] 6.1 Loading states are displayed while data is being fetched (Frontend only)
+  - [ ] This is only implemented in the existing pages, you'll need to implement this for all the additions you make too!
+- [ ] 6.2 Meaningful error messages are shared when actions fail
+- [ ] 6.3 Form inputs are validated before submission (Frontend only)
+
+## 7. Admin and Reporting (optional idea)
+
+<!-- TODO: I'm not sure if we should include a list of optional ideas here too, but here's one for now -->
+
+- [ ] 7.1 Admins can view ticket sales statistics per event (e.g. tickets sold, revenue)
+- [ ] 7.2 Admins can see an overview of all events and their performance
diff --git a/shared-modules/mid-specialism-project/temp-planning-notes.md b/shared-modules/mid-specialism-project/temp-planning-notes.md
new file mode 100644
index 00000000..b999b79b
--- /dev/null
+++ b/shared-modules/mid-specialism-project/temp-planning-notes.md
@@ -0,0 +1,16 @@
+# Temp Planning Notes
+
+<!-- TODO: These are planning notes to be removed or moved before going live -->
+
+We will create two apps, frontend and backend, from [hyf-project-template](https://github.com/HackYourFuture-CPH/hyf-project-template). Both courses should start with some state of runnable, working app. The starting point is up to us. They should have some code they have to "work out" at the start, just like when you start in a new job.
+
+**Backend:**
+
+- Basic API, runnable
+- Initial API docs in place
+- Initial database
+
+**Frontend:**
+
+- Basic frontend app, runnable
+- Fully working, documented API via json-server, easily editable