Fix layout

.github/workflows/build_pdf.yml

@@ -37,10 +37,10 @@ jobs:
 
       - name: Generate PDF
         run: |
-          swent_prd generate --team 26 template
+          swent_prd generate --team 9 template
 
       - name: Upload PDF as artifact
         uses: actions/upload-artifact@v3
         with:
           name: PRD-PDF
-          path: Team_26_prd.pdf
+          path: Team_9_prd.pdf

template/0-heading.md

@@ -1,4 +1,4 @@
-# MVP PRD: Project Name
+# MVP PRD: Echo
 
 *[2024.04.20]*
 

template/10-timeline.md

@@ -1,10 +1,67 @@
+*What resources are required?*
+
 # Timeline/Resource Planning
 
-*What’s the overall schedule you’re working towards?*
+## Execution Roadmap
 
-*What resources are required?*
+The MVP development will be completed over a 14-week period, including setup, development, testing, rollout, and feature iteration. The team consists of 1 frontend developer, 1 backend developer/DevOps engineer, 1 part-time UI/UX designer, and 1 part-time software tester.
+
+### Milestone 1: Design Completion and Technical Setup
+
+- Document APIs, request-response parameters
+- Develop UI elements for profile creation and event discovery: dropdowns, filters, buttons, etc.
+- Create Figma mockups and user flow documents
+- Implement user registration and integration
+- Conduct initial tests to populate UI elements with sample data
+
+| **Sprint/Week Number** | **Objective** | **Outcomes** |
+| --- | --- | --- |
+| Week 1 | Kickoff and Documentation | Investigate APIs, document them, create scraping prototype scripts, set up project tools, and establish MVP scope. |
+| Week 2 | Design and Technical Setup | Create initial wireframes and user flows, start UI mockups with elements for event discovery, configure user registration and integration. |
+| Week 3 | Design Finalization & Application Skeleton | Finalize UI/UX designs, set up development environments, and create backend APIs to populate simple UI elements. |
+
+### Milestone 2: Core Feature Development
+
+- Prototype core features weekly with appropriate API mock integration
+- Test on multiple devices; refine design for different screen sizes
+
+| **Sprint/Week Number** | **Objective** | **Outcomes** |
+| --- | --- | --- |
+| Week 4 | Event Discovery Feature Development | Develop the event discovery feature end-to-end, integrate frontend-backend, begin unit testing. |
+| Week 5 | Event Participation Feature Development | Complete the event participation feature, continue integration and unit testing, support multiple device types. |
+| Week 6 | Association Admin Interface Development | Develop the admin interface for associations, integrate all features in the frontend, conduct internal testing. |
+| Week 7 | Unit and Integration Testing | Write remaining unit tests, verify frontend-backend integration with integration tests. |
+
+### Milestone 3: Internal Testing and Pre-Launch Preparation
+
+- Conduct end-to-end tests on multiple devices
+- Perform stress testing for peak load, average load, and API latency
+- Implement error handling and logging for API failures
+
+| **Sprint/Week Number** | **Objective** | **Outcomes** |
+| --- | --- | --- |
+| Week 8 | Internal Testing & Analytics/Monitoring Pipelines | Conduct thorough internal testing, load testing, gather feedback, fix bugs, and perform performance testing. |
+| Week 9 | Pre-Launch Preparations | Address final bug fixes and optimizations, prepare app store and launch materials. |
+
+### Milestone 4: Initial Rollout and Feature Iterations for PMF
+
+- Roll out the app to alpha testers
+
+| **Sprint/Week Number** | **Objective** | **Outcomes** |
+| --- | --- | --- |
+| Weeks 10-11 | Initial Rollout/Alpha Testing | Deploy the app to production, monitor performance, gather user analytics and feedback, implement hotfixes as needed. |
+| Week 12 | Feature Iteration 1 | Identify drop-off points, optimize user experience, roll out updates, and improve the UI. |
+| Week 13 | Beta Testing | Initiate marketing, onboard users, promptly address feedback to build trust. |
+| Week 14 | Full Rollout | Intensify marketing efforts, offer incentives for app downloads, such as free meals for lucky winners. |
 
-*What are the intermediate milestones?*
+## Development Resources
 
-*List identified sprints*
+The primary cost of developing the product will be the developers' salaries. We estimate the need to secure four months of funding for a four-person team to accommodate both planned and unforeseen scenarios. Realistically, this project requires two full-time developers (one frontend, one backend/DevOps), along with two part-time contractors for UI design and testing. We expect the contractors to contribute a total of two person-months each over the 4-month development and go-to-market timeframe. We will allocate additional funds for a total of four person-months to cover unexpected deviations from our roadmap.
 
+| **Function** | **Required Person-Months** |
+| --- | --- |
+| Frontend Developer | 4 |
+| Backend Developer | 4 |
+| UI/UX Designer | 2 |
+| Software Tester | 2 |
+| Surplus Cash Reserves | 4 |

template/11-monetization.md

@@ -1,6 +1,13 @@
 # Business Model
 
-*Expected operating Costs*
+### Expected operating cost
+The operating costs of our app are proportional to the number of users. The choice of Supabase allows us to avoid vendor lock-in if it becomes too costly to pay for the database and storage. The pricing page of Supabase shows us that 25$ per month is sufficient for 100'000 monthly active users. Then the cost per user increases, but thanks to the fact that Supabase can be deployed on our own hardware, we can keep the cost down. For example, if we decide to deploy Supabase on a virtual private server, we estimate that it will cost only 0.00015$ per month per monthly active user. We clearly see that these operating costs are small.
 
-*Revenue Streams*
+### Revenue stream
+The revenue stream of our app comes from mutliples sources.  
+First, we can collect some group behavior data from our users. For example, which categories of events are the most successful, or what's the best location for an event to be successful. With these insights on our users, we can introduce an optional monthly subscription of 5$ for the associations which want to improve their chances to organize a successful event.  
+Second, we can develop themed versions of the app for special occasions. For example a week-long event on a big area with a lot of events in parallel, like CES, could ask us to create a special app for the occasion that would allow the participants to have an overview of all the events, join some of them and find them easily on the map. This would occasionally bring us a big income, probably about 10'000$ per mission.  
+Third, we can monetize some services in our application, which allows the associations to have easy integration of all the things that come with the organization of an event. For example, a ticketing system can easily be added to our app. The user could buy a ticket for a paid event without needing another app or website. The associations would have some management interface with the participant to allow easy verification, refunds, and more. We just take a small fee on the ticket price, for example, 5%.
 
+### Extrapolation
+In total, we estimate that if our app becomes successful enough to be adopted by 1'000'000 users, with 200 associations that pay for premium features and 5'000'000$ worth of tickets per year, we can estimate a minimal cost of 15$ per month and a revenue of about 252'000$ per year. This gives us a consistent income that will allow us to develop more features for our app.

template/12-appendix.md

@@ -1,6 +0,0 @@
-# Appendix
-
-*This section is optional.*
-
-*Can include mockups, sequence diagrams, etc.*
-

template/2-history.md

@@ -8,3 +8,6 @@
 
 *What is missing to bridge from PoC to MVP?*
 
+* Basic features such as joining and creating events.
+
+* Missing: lacking features which enable users to communicate amongst themselves.

template/3-analysis.md

@@ -4,3 +4,6 @@
 
 *What are the complementary products in the market today?*
 
+* Currently, students are notified of the events on campus through emails or through unofficial telegram channels or instagram accounts. 
+
+* There is a certain need to regroup all the information at one place such that the user only sees events which interest them.

template/4-value_proposition.md

@@ -1,10 +1,45 @@
 # The Value Proposition
 
-*Describe the value proposition and argue that it is:*
+Echo offers a centralized platform both for potential event participants and event organizers. Organizers are offered facilities to create events and
+share them to targeted users (e.g. followers) but also to the general public. Said audience is able to find, discover and be notified of events geared
+to their interests. The relationship between participants and organizers is the cornerstone of our value proposition.
+While our POC was definitely geared towards users on the audience end of the relationship, our vision is to offer value to both ends.
 
-*1. Easy to communicate*
+To the audience, we offer:
 
-*2. Defensible*
+- A user-friendly tool to find events aligned with their interests and hobbies, or to expand them by discovering nearby events from previously unkown categories.
 
-*3. Relevant*
+- A personnalized feed of recommendations for events they might want to attend.
+At the beginning, the feed is based on simple user analytics, such as tags in their profile, in that of their friends or in the associations they follow,
+but also on their activity: events that they, or their friends, have participated in, interactions with said events, etc. This value would
+only increase with time and growth of user count, as more data would allow for more complex sorting algorithms.
+
+- A platform to stay informed in real-time about events happening around them.
+
+To the event creators, we offer:
+
+- A platform where they can share their events with known participants, but that also allows them to reach new audiences.
+
+- A platform to centralize all their hosting related needs: ticketing, advertising, real-time communication with participants.
+
+Most associations at EPFL are familiar with the struggles of hosting events, such as finding participants or dealing with communication and
+advertising.
+Echo offers a clear benefit to them because it provides direct support in these struggles.
+Furthermore, there is nothing specific to EPFL about these pain points, so we can safely affirm that this benefits apply to any association or
+individual hosting an event, which is why, even if EPFL would be our starting point, the value we provide supercedes any geographical boundary.
+
+Furthermore, Echo presents itself as an attractive tool to potential participants, because it removes
+the need to scrape their social media feed, their mailbox and the web just to find an enjoyable activity to participate in.
+
+Echo offers particular value to individuals looking to meet new people, make new friends and improve their social insertion.
+
+Echo is definitely relevant to the EPFL student population, students probably being the most frequent creators of events and the most frequent participants.
+Nonetheless, as long as anyone is free to create and share an event about anything, Echo will find its relevance even in the smallest population
+segments.
+
+At its core, Echo provides a wide array of services to both participants and organizers, and a number of such services will include a small fee (e.g. for ticketing).
+
+Finally, the nature of the app makes it particularly easy to collect advertising fees, or even to strike deals with companies who wish to promote their events.
+
+However, Echo must ensure that said monetization doesn't interfere in any significant way with customer acquisition or with the usability of the app.
 

template/5-mvp.md

@@ -1,34 +1,73 @@
 # The MVP
 
-## Personas and Scenarios
+## Personas & Scenarios
 
-*Who are the target personas for this product?*
+Echo is intended for EPFL students, with first-year students as the key persona. It is these students 
+who would benefit most from the application, as many of them don't know anyone yet. Although our school 
+organises groups to meet in BA1 (Coaching), it doesn't provide as personalised an experience as Echo. 
+If successful, we aim to replace/improve this service. In addition, our application offers events for 
+all levels, which is beneficial for our second and third personas: exchange students and repeaters.  
+Our fourth persona is students from all other years who want to meet new people or do an activity with 
+other enthusiasts. Our last persona is the associations. They are the first to organise events on campus 
+and struggle to promote their activities. Our application would give them extra visibility.
 
-*Which is the key persona?*
+## User Stories
 
-*High-level scenarios to adopt, use and share the product.*
+### User Story First-Year Student
 
-## User Stories and Key Features
+1. As a first-year student, I want to be able to take part in events with my class to meet people I can work with.
 
-*User stories about how various personas will use the product in context.*
+### User Story Exchange Student
 
-*Identify and prioritise the key features required.*
+1. As an exchange student, I want to be able to take part in EPFL public events so that I can integrate more easily into my new environment.
 
-*Justify the importance of each feature.*
+### User Story Repeater Student
+
+1. As a repeater student, I want to be able to get to know my new classmates so that I have people to take classes with. 
+
+### User Story All EPFL Students
+
+1.	As an EPFL student, I want to be able to join events to pursue my passions.
+2.	As an EPFL student, I want to be able to meet new people who share the same passion as me so that I can make new friends
+
+### User Story Association
+
+1.	As an association, I want to be able to promote my events in order to have more participants.
+
+## Key Features
+
+The main aim of Echo is to bring EPFL students together. That's why our application allows them to organise events around their passions, bringing together students from the same class or section. The key to our success lies in the number of events actually organised. Key features of our app include:
+* Event participation - This is the most obvious feature, offering our users the chance to discover personalised events based on their passions and curiosity. They can easily find them thanks to a powerful search tool and profile customisation.
+* Getting to know people from the same background - Coming to EPFL can be difficult, especially if you don't know anyone. Echo is keen to encourage people from the same class or section to get to know each other, so students can organise events restricted to a certain milieu. 
+* Associations - At present, the associations are by far the most active in creating events on campus. However, they all have the same problem: a lack of participants. Echo enables associations to promote their events to users and reach their target audience more easily.
 
 ## Success Criteria
 
-*How will you evaluate the success of the MVP?*
+### Event Creation
 
-*Metrics include user penetration, quality / satisfaction.*
+To assess the success of Echo, we will be looking at the number of events officially held. We estimate that an event brings together an average of 10 people. Our application will be a success if we manage to organise at least 1 event per week for every 100 students. So, for a first-year computer science class of 600 students, at least 6 events should be organised within this class using our application. We will also look at the number of people attending the event per person registered as a participant. We should achieve an attendance rate of 80%.
 
-*If applicable, progress in discussions with ecosystem partners / investors / customers.*
+### User Adoption & Engagement
 
-## Features Outside the Scope
+* In its first month at the start of the academic year, our application plans to reach at least 30% of new EPFL students (first-year, exchange and repeat students ~ 1,000 users), and at least 10% of the rest of the student body (~ 1,000 users). 
+* Since our events are generally organised on a weekly basis, we're mainly expecting weekly rather than daily users. Our aim is to achieve a DAU of 5% (100 users) and a MAU of 80% (1,600) in the first month of its launch.
+* We expect the application to be used a lot at the beginning of the semesters and then to be put to one side slightly at the end of the semester/exam periods. However, we still expect to be able to achieve a retention rate of at least 50%.
+
+### Feedback & Satisfaction
 
-*The MVP must be viable and minimal.*
+* We hope to achieve a score of 4 stars out of 5 in the Play Store ratings. We will be regularly monitoring feedback to identify recurring comments about our application, and adapting our approach accordingly.
+* A survey will be carried out at the end of each month to respond to requests from users who would like to add new categories, and to ensure that each of them has at least one event available per week. This will enable us to assess demand and, why not, try to improve the visibility of certain activities that are struggling to develop (special events organised by the application).
+* A survey in order to know the user experience with the app so far and if they would recommend it to their peers or if they like the application enough to continue using it.
+Maybe include like time to time popups like we have on certain applications which ask the user for feedback by rating the app in order to know user feeling about the same.
 
-*Which features don’t belong in it.*
+### Association Implication
+
+* Contacting all the associations to offer them the use of our application
+* Success would mean serving 70% of EPFL's associations
+
+## Features Outside the Scope
 
-*How should these be eventually integrated and in what sequence.*
+* Exclusion of AI to recommend events - One of the things we wanted to do for our application was to introduce users to new activities using a recommendation algorithm. Based on our users' habits, we could train an AI to come up with a viable model. This feature is out of scope because we don't currently have any users, and we haven't found any data accessible online of sufficiently good quality to have a good model. But it's still worth keeping aside in case we have the necessary resources.
+* Exclusion of a multi-tenant Saas - What we're doing with EPFL could very well be replicated for every other school, company or region. Creating a more universal application, while remaining customisable for each environment, is a step we haven't yet explored. To begin with, it was simpler to focus on a structure that we knew well, the EPFL. The advantage of making it a multi-tenant SaaS is that it allows users to get used to using a single application regardless of the environment in which they find themselves. In this way, Echo could become for events what What's app is for communication.
+* Exclusion of a tiered trust system - We currently allow all users to create and join events. While this fosters an open environment, it also presents potential risks of misuse. To address this, we envision a tiered trust system. New users would gain event creation privileges after a period of responsible use (e.g., 3 months). We understand this may not be feasible initially with a limited user base. Therefore, we'll be implementing manual moderation to ensure a safe and positive experience for all.