diff --git a/.github/workflows/build_pdf.yml b/.github/workflows/build_pdf.yml index 96675673..7ea34ca0 100644 --- a/.github/workflows/build_pdf.yml +++ b/.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 diff --git a/template/0-heading.md b/template/0-heading.md index ba21a556..7b4ea53e 100644 --- a/template/0-heading.md +++ b/template/0-heading.md @@ -1,4 +1,4 @@ -# MVP PRD: Project Name +# MVP PRD: Echo *[2024.04.20]* diff --git a/template/10-timeline.md b/template/10-timeline.md index a4efa719..8ed71a73 100644 --- a/template/10-timeline.md +++ b/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 | \ No newline at end of file diff --git a/template/11-monetization.md b/template/11-monetization.md index 04263a3f..0a5d7194 100644 --- a/template/11-monetization.md +++ b/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. diff --git a/template/12-appendix.md b/template/12-appendix.md index 377bc045..e69de29b 100644 --- a/template/12-appendix.md +++ b/template/12-appendix.md @@ -1,6 +0,0 @@ -# Appendix - -*This section is optional.* - -*Can include mockups, sequence diagrams, etc.* - diff --git a/template/2-history.md b/template/2-history.md index 3372784b..96d60da1 100644 --- a/template/2-history.md +++ b/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. diff --git a/template/3-analysis.md b/template/3-analysis.md index 509fbb0b..ed6743e8 100644 --- a/template/3-analysis.md +++ b/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. diff --git a/template/4-value_proposition.md b/template/4-value_proposition.md index 449ebbcb..ca6094e2 100644 --- a/template/4-value_proposition.md +++ b/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. diff --git a/template/5-mvp.md b/template/5-mvp.md index c735be65..3f18a1fe 100644 --- a/template/5-mvp.md +++ b/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. diff --git a/template/6-non_functional_requirements.md b/template/6-non_functional_requirements.md index 76b0e5f5..8a99942a 100644 --- a/template/6-non_functional_requirements.md +++ b/template/6-non_functional_requirements.md @@ -2,15 +2,14 @@ ## Security, privacy, and data retention policies -*Which are the applicable laws and regulations?* +Our app collects the minimal amount of data on our users needed for it to be fully functional. This way, we avoid the collection of "sensitive" data that could be subject to special regulations in certain countries. Most of the data in our app is accessible publicly; the only thing that needs to be protected is the user's email and password. Supabase seems reliable enough to avoid leaking such information, and in any case, the password is stored hashed with a salt. We can easily inform all the users if a data breach happens because we have their email. -*What are your internal policies?* +From a privacy standpoint, the most sensitive information we have is the participation of the users in the events and the user profile. A user can only access their own user profile in the app, and he cannot see a list of subscribed users to an event. Our app minimizes the data it collects, and we don't sell or give direct access to this data. The analytics aggregations will have to be done on the events, as the users never send their location to the server. We don't ask for other permission than location, and we use intends that return a single item to get data from other apps (i.e. set the profile picture). -*Which privacy features do you need from the phone?* +We can automatically delete the user accounts after some time of inactivity, and a user can email the support if he wants to have a copy of all the data we have on him. Furthermore, we plan to add a delete account button in the app. ## Adoptions, Scalability and Availability -*What kind of traffic patterns do you expect to see?* - -*Are there known periods of bursty traffic that the MVP must be designed to support?* +Obviously, our first focus is the EPFL campus. Then we can promote the app to the whole population, as there is a very low entry barrier. We don't limit the app's usage, so anybody in the world could just use it, but since the app is only available in French or English, it limits its worldwide usage. However, thanks to our modular architecture, it's quite simple to translate the app into any language we want. +We will probably have high traffic during non-working hours. We should make sure with a stress test on the database that it doesn't impact too badly the performance of the app. Since we have caching capabilities in the app, we are able to reduce the load spikes. If some events are very big (i.e. Balelec) we can also plan to scale up our backend for the duration of the event to avoid any issues. diff --git a/template/7-functional_requirements.md b/template/7-functional_requirements.md index 1a322ee1..0fe36d84 100644 --- a/template/7-functional_requirements.md +++ b/template/7-functional_requirements.md @@ -1,10 +1,23 @@ # Functional Requirements -*Max 3 pages.* +## Key MVP Features -*List the key features of the MVP precisely.* +### Discovering Events -*Include appropriate architectural diagrams.* +The process of discovering events should be seamless and straightforward for our users. Our goal is to enable users to open the app and find events that pique their interest within five minutes. Achieving this will require robust profile personalization and a sophisticated algorithm designed to match events with users accurately. -*Describe key internal functionality.* +To ensure users get the most out of their profiles, the profile creation process will be guided and intuitive. Central to the event discovery process is the matching algorithm. To develop an effective algorithm, we will conduct a thorough review of existing solutions in the literature and refine our approach through intensive testing with beta users. We are confident that we can draw valuable insights from recommendation algorithms used in various social media platforms. +### Participating in Events + +User participation in events is crucial for the success of our app. We aim to make the process of joining events as effortless as possible. Users should be able to join an event with no more than two clicks. To encourage participation, we will incorporate a prominent call-to-action button that makes it easy for users to engage with events they find interesting. + +### Helping Associations Promote Events + +Associations, as the primary creators of events, are vital to our platform. We aim to support them in making their events successful by providing them with a comprehensive admin interface. This interface will allow them to track event registration progress and compare current events with past ones. The admin interface will be designed to be highly intuitive and user-friendly, offering a wide range of customization options to meet the specific needs of each association. + +## Key Internal Functionality + +Given the potential computational demands of our algorithm, we plan to run it on our backend servers. This approach will ensure that users do not need to download all event data and rank them by interest on their devices, which would be inefficient and resource-intensive. By handling the heavy lifting on our backend, we can provide a smooth and efficient user experience. + +![](./assets/app-server.png) diff --git a/template/8-user_analytics.md b/template/8-user_analytics.md index 3fdb9feb..3bce9084 100644 --- a/template/8-user_analytics.md +++ b/template/8-user_analytics.md @@ -1,12 +1,26 @@ # User Analytics and Acceptance -*Goal: understand how users are using the app.* +## Usage metrics -*Which are the key metrics?* +Feature use : What screens are the most used -*What is the success criteria?* +User retention : Rate of users that keep using the app -*What is the analysis plan (link to data collection)?* +User engagement : Users interactions with events (creation, joining, searching) -*Include relevant A/B testing ideas.* +## Success criteria +1. High user engagement and retention +2. Feature use is balanced, and no features are underused +3. Zero to few crashes or bugs + +## User analytics + +1. Implement google analytics for behavioral tracking +2. Anonymize data for privacy + +## A/B testing ideas + +1. Experiment different graphical layouts to display events or associations. +2. Test navigations flows to make sure layouts are user friendly. +3. Make overviewed user tests for the UI diff --git a/template/9-design.md b/template/9-design.md index d9872a1d..ae1e2e3d 100644 --- a/template/9-design.md +++ b/template/9-design.md @@ -2,35 +2,117 @@ ## Frontend -*List the key libraries, languages, components used by the MVP.* +### Implementation framework -*If applicable, describe essential screens.* +The app is developed in Kotlin using Jetpack Compose using an MVVM architecture. The repository architecture is used for having a single interface for all data. + +Furthermore the following libraries are used: +- Supabase: interaction with the backend +- Google Auth: for users wishing to sign in using it +- Maplibre: for a modern vector-rendering map; the central element of the app +- Google Play Location Service +- Hilt: depenency injection +- Room: local DB for synchronisation and caching + + +### Primary screens +- Main screen: map with events, allowing searching and filtering and discovery +- Secondary screen: list mode for events; the same search/filtering is applied +- Other screens: + - My Events: allows to see created and joined events + - My Profile: allows to modify the users profile + - Create Event: screen to create events + - Associations: shows associations and the relation the user is with them (following, committee member) ## Backend -*Decompose the MVP into functional blocks.* +The backend server hosts all necessary data and enforces access policies. We are using Supabase which combines a series of industry standard tools into a nice consolidated API with its library. Supabase provides authentication of users (additionnaly via Google OAuth), storage of structured data and object storage for files. +Access and modification is restricted based on the type and ownership of the element. ## Data Model -*What data are you collecting / managing?* +Alll the structured data i stored in the PostgreSQL database integrated into Supabase. -*How is it organised?* +### Authless Data -*Where is it stored?* +#### Tags -*How is it shared/copied/cached?* +Purpose - Contains all the available tags. Tags include categories of type of events/interests as well as specific ones like Sections or Semester for the campus context. -## Security Considerations +Fields - Tag Id (Primary Key), Name, Parent Id -## Infrastructure and Deployment +#### Events -*How is the application developed, tested and deployed?* +Purpose - Contains information about all events added to the app. -*Any special infrastructure requirements.* +Fields - Event Id (Primary Key), Creator Id, Organizer Id, Title, Description, Start Timestamp, End Timestamp, Location (Name, Long, Lat), Participant Count, Max Particiants -## Test Plan +##### Event Tags + +Purpose - Records represent tags assigned to an event. + +Fields - Tag Id (Foreign Key), Event Id (Foreign Key) (Composite Primary Key) + +#### Associations + +Purpose - Contains information about the validated associations. + +Fields - Association Id (Primary Key), Name, Description, Url + +##### Association Tags + +Purpose - Records represent tags assigned to an association. + +Fields - Tag Id (Foreign Key), Association Id (Foreign Key) (Composite Primary Key) + + +### Auth UserData + +#### User Profiles + +Purpose - Contains information about the user + +Fields - User Id (Foreign Key) (Primary Key), Name + +##### User Tags -*How is the application developed, tested and deployed?* +Purpose - Records represent tags assigned to a user. -*Any special infrastructure requirements.* +Fields - User Id (Foreign Key), Tag Id (Foreign Key) (Composite Primary Key) + +##### Association Subscribtion + +Purpose - Records represent users which follow associations. + +Fields - User Id (Foreign Key), Association Id (Foreign Key) (Composite Primary Key) + +##### Committee Member + +Purpose - Records represent which users are member of a committee of an association and therefore get the right to publish in the name of the association. + +Fields - User Id (Foreign Key), Association Id (Foreign Key) (Composite Primary Key) + +##### Event Joins + +Purpose - Records represent a user having joined (e.g. signed up for) a specific event. + +Fields - User Id (Foreign Key), Event Id (Foreign Key) (Composite Primary Key) + + +##### User Profile Picture + +Profile pictures are stored as objects in the S3 bucket; access is restricted based on the ownership of the object. + +## Security Considerations + +Storage of user data is limited to the strictly required data for the app to work. +RLS (Row Level Scurity) policies restrict access to resources, preventing unauthorized users to access personal information like which events are joined by a given user. They also prevent modification of data by unauthorized users. +Additionally in accordance to GDPR compliability, the app will allow to completely delete all data of a given user. + +## Infrastructure and Deployment + +The primary infrastructur is a Supabase instance wich is currently hosted by Supabase themselves on Amazon AWS. The option to selfhost Supabase on whatever infrastructure (included on premise) exists. + +## Test Plan +We will write integration tests for all possible user stories. Furthermore also the interaction with the backend service will be tested in a test environment. This helps to catch potential edge-case situations in interaction of multiple users. diff --git a/template/assets/app-server.png b/template/assets/app-server.png new file mode 100644 index 00000000..f5dcde88 Binary files /dev/null and b/template/assets/app-server.png differ