Our project, Community Garden Planner, is a web application designed to support collaborative gardening through two primary features:

• Garden Task Management: Users can create gardens by providing details such as name, description, and location. They can manage garden membership by approving or rejecting join requests, assign tasks to members, and track task progress. Users can also search for and join other gardens.

• Gardening Forum: A dedicated forum allows users to post gardening-related content, ask questions, share tips, and comment on posts to foster a helpful and active gardening community.

Although we did not implement every feature initially specified in the project requirements, we successfully delivered all core functionalities. These include user registration and login, forum participation (viewing, posting, commenting), garden creation and joining, task assignment and tracking, and user profile management.

We met most of our original project goals. Given time constraints, we made deliberate decisions to prioritize essential features over some planned extensions. As a result, the application is fully functional and has been deployed.

There are a few known minor bugs — for instance, profile information is not viewable from certain tabs — and some enhancements remain for future development. Nonetheless, the application is ready for demonstration and general use.

• Issues & PRs: Issues created for almost all of the work done by the team. Issues are properly commented and closed. PRs are properly reviewed and merged. All closed issues can be found here. All closed (merged or unmerged) PRs can be found here.

• Wiki: You can check out our wiki home page to access all documentation related to our project such as project requirements, scenarios, diagrams, demos etc.

  • Communication Plan: Communication plan is stated in the home page and the team communicated according to the plan throughout the project along with additional solutions such as impromptu meetings and texting.
  • Requirements: Requirements went through several revisions and is up to date. Requirements page does not only include the implemented features by the project (e.g. FR 1.1) but also the desired features for future enhancement (e.g. FR 6.1).
  • Scenarios: Scenarios are listed in the home page. We have a total number of 10 user scenarios that meet the standards and provide a variety of application usage. They are not perfectly applicable in the current status of the project since they include features remaining for future development, however main goals are satisfied thanks to the implemented core features.
  • Research: Our research for git resources is documented in our dedicated wiki page.
  • Meeting Notes: Our team meetings are documented by the note taker of the meeting. They are documented clearly and concisely, they include details like date, location, duration and the note taker, attendees, agenda, discussion topics and decided actions.

• Project Plan: We initially planned our work with determining deadlines in weekly team meetings (as seen in the example) and tracked issues with status labels (not started, in progress and in review). Later on in addition to that we created a backlog, we categorized the issues by 6 different status: Waiting due to dependancy, todo, in progress, waiting for review and done. We established a roadmap in our 7th weekly team meeting. Perfectly following this roadmap proved not to be possible for various reasons such as decreased team capacity and preparation times, so we decided to roughly follow the iterations, not strictly.

• Implementation: Our completed code is merged to the main branch. All the implemented code for backend, frontend and mobile can be found there.

  • Backend: Implemented endpoints for features garden creation, joining gardens, accepting users to gardens, creating/assigning/accepting/declining/completing/self-assigning tasks, creating custom task types, forum posting/commenting, login/register, password reset, user profiles, following/blocking users, and fetching weather data. API URLs can be found here. Implemented views can be found here.
  • Frontend: Implemented all the features backend provided except accepting/declining/completing tasks. Additionally implemented captcha verification for logging in and registering.
  • Mobile: Implemented all the features backend provided except custom task types and password reset. Additionally implemented captcha verification for logging in and registering.

• Demos: Demo videos for frontend and mobile can be found here.

• Issue Management: Issues are created and assigned after team meetings or individually during work. They are created with 6 different template choices: Bug report, documentation improvement, feature request, meeting, questions or review request. They are labeled with related team (backend,frontend or mobile), priority (low, medium or high), status (not started, in progress or in review) and other types (meeting, review, design, documentation etc.). They are tracked by their status and issues that can't be done by the assignee on time are taken over by a volunteer.
• Meetings: Meetings are done weekly with respect to the communication plan and documented in the wiki. Other than that we decided to create a whatsapp group for instant communication, planning impromptu meetings and quick work re-distributions. We chose note takers and moderators in alphabetical order for equality. Moderators ensured meetings go smoothly.
• Wiki Documentation: We decided to document meeting notes following a meeting notes template. We ensured that all the pages are accessible via the home page and the sidebar. We assigned reviewers for all changes made in the wiki.
• Branch and PR Management: We restricted direct pushes to main branch. We made at least 2 approvals from reviewers mandatory for PR merges. We used development branch for merges until the final merge. Our branch naming conventions and any other PR details can be found in our contribution guidelines.

Throughout the semester, our team encountered several challenges that impacted the development and coordination of the project. The academic boycott, along with the earthquake and the resulting suspension of classes, led to a highly irregular academic schedule. These disruptions made it difficult to maintain consistent progress and communication within the team. Furthermore, as the project advanced, a few team members either left or became unresponsive, which created additional pressure on the remaining members. These circumstances required us to adapt our workflow, redistribute responsibilities, and find alternative ways to ensure the project could be completed despite the setbacks.

We experienced technical issues during deployment to DigitalOcean, particularly with our containers and backend connectivity. Although everything functioned correctly in our local environment, some unexpected errors occurred after deployment. We resolved these issues by debugging locally, identifying the root causes, and then redeploying the updated version to the server.

Another significant challenge was the disorganized and inconsistent state of our repository, including diagrams, documentation, and meeting notes. Over time, as the project evolved, these resources became fragmented and difficult to manage. We had to dedicate several weeks to reviewing, cleaning up, and reorganizing all project materials to ensure consistency, clarity, and better collaboration moving forward.

To track our issues, we used a Task Board from GitHub projects. It can be accessed here. This helped us with status updates and easily addressing unassigned tasks from the backlog. We did not use the iterations part of GitHub Projects under Roadmap tab effectively, yet we tried to match our completed issues to iterations that they would fall into before submission.

However, as mentioned before, the kanban board was of great use to us for the whole project duration. We used it effectively with custom columns to track task assignments and status.

Milestone	Description	Date	Status
Project Initialization	Set up GitHub structure, team pages, and templates	Feb 11 - Feb 24	Completed
Requirement Analysis	Create glossary and requirements, customer meeting, elicitation	Feb 24 - Mar 10	Completed
Design	Create scenarios, use cases, class, sequence diagrams	Mar 11 - Mar 30	Completed
Eid	-	Mar 31 - Apr 4	-
Implementation	Mobile and Web Development	Apr 5 - Apr 27	Completed
Spring Break	-	Apr 28 - May 5	-
Submission Milestone	Implementation, Integration, Deployment and Submission	May 6 - May 14	Completed

Above are the phases that our project went through, again noting that we did not use iterations. Before implementation, we decided to have a detailed roadmap for the month ahead of us. It can be found here among meeting notes #7. However, due to many external factors, we were not able to keep up with it, so we made reductions.

The frontend of the Community Garden Planner application is built using modern web technologies:

• React 19: The application is built using the latest React version, providing efficient rendering and component-based architecture.
• Vite: Used as the build tool and development server, offering fast refresh and optimized production builds.
• React Router v7: For client-side routing and navigation between different pages of the application.
• Material UI v7: The UI component library that provides a cohesive design system with customizable components.
• nginx: Used for serving the application in production, providing static file serving and reverse proxy capabilities.
• Docker: For containerization, ensuring consistent environments across development and production.
• Vitest and React Testing Library: For testing, providing a fast and efficient testing framework for React applications.

The project follows a feature-based architecture:

• /src/components: Reusable UI components with separation of concerns (e.g., TaskBoard.jsx for drag-and-drop functionality, GardenCard.jsx for garden visualization)
• /src/contexts: Context API implementations with AuthContext.jsx handling JWT authentication flow and user state persistence
• /src/pages: Feature-scoped page components organized by domain (auth, garden, forum, profile, task)

The application implements JWT-based authentication with React Context API. The AuthContext provides:

• Token persistence via localStorage with automatic restoration on page reload
• Encapsulated authentication methods (login, register, logout) with token management
• User state management with React's useState and useEffect hooks
• Protected route handling with conditional rendering in the routing configuration

• Responsive Design: Implemented with Material UI's breakpoint system (xs, sm, md, lg, xl) and responsive spacing units.
• Custom Theme Implementation: Theme extends Material UI with primary colors (#558b2f, #7cb342, #33691e) and secondary colors (#ff9800, #ffb74d, #f57c00), coupled with responsiveFontSizes for adaptive typography.
• Component Styling: Global style overrides through theme.components configurations, including custom border radius (8px), button transformations, and elevation effects on hover states.

1. Garden Management

   • Garden listings with card-based UI
   • Detailed garden view with information and interaction features

2. Task Management

   • Drag-and-drop task board using @hello-pangea/dnd library
   • Task categorization by status (Pending, In Progress, Completed)

3. Forum System

   • Post listings and detailed view
   • Comment creation functionality

4. Weather Widget

   • Integration with Open-Meteo API for weather forecasts
   • Geolocation-based weather data

5. Calendar Integration

   • Event scheduling using @mui/x-date-pickers with dayjs

The project uses Vitest with React Testing Library for component testing. Test files are co-located with their implementation files for better organization.

The application uses Docker for containerization and includes Nginx configuration for production deployment. The build process is handled by Vite with optimizations for production.

• UI Components: Material UI core and icons
• State Management: React Context API for global state (Authentication)
• Form Handling: Native React form handling
• Notifications: react-toastify for toast notifications
• Drag and Drop: @hello-pangea/dnd for task board functionality
• Date Management: dayjs with MUI date pickers

• ESLint for code linting with Airbnb configuration
• Testing setup with Vitest and React Testing Library

The backend of the Garden Community App was developed using Django and Django REST Framework, following a modular and scalable architecture. Key features were implemented to support secure authentication, garden and task management, user interactions, and external integrations.

🔑 Authentication & Authorization

• Implemented token-based authentication with login, logout, registration, and password reset endpoints.

• Designed a Role-Based Access Control (RBAC) system to manage permissions across gardens and tasks.

• Context-aware access rules were enforced throughout API endpoints based on user roles (e.g., manager vs. worker).

👥 User & Profile Management

• Created profile endpoints for retrieving and updating user data.

• Implemented block/unblock functionality for managing user interactions securely.

• Developed /memberships/my-gardens endpoint to support personalized views in the mobile client.

📅 Garden & Task Management

• Developed comprehensive garden APIs including creation, membership management, and role updates.

• Task endpoints support assignment workflows, self-assignment, and status updates (accept, reject, complete).

• Extended the forum system to support task-related post types for integrated discussion and delegation.

🌐 External Integrations Integrated the Open-WeatherAPI to provide real-time weather forecasts based on geolocation.

• Integrated the Captcha API to prevent program from suspicious login requests.

• Ensured API consumption was consistent with frontend components via shared parameters and token handling.

🧪 Testing & Quality Assurance

• Performed unit and integration testing using Django’s test framework and Postman.

• Debugged and validated test cases, including for third-party API integrations.

📦 Infrastructure & DevOps

• Dockerized the backend application for environment consistency and deployment readiness.

• Addressed configuration issues during deployment (e.g., host IP adjustments, production-specific settings).

Can find PR and issue links below on contribution table, more detail regarding the implementation are described in corresponeding PR comments throughly.

Technology Stack

The mobile version of the Garden Community Planner was built with modern cross-platform tooling:

• React Native (Expo SDK 50): Provides native app functionality across iOS and Android using JavaScript/TypeScript.
• Expo Router: Enables file-based routing and navigation in the app, inspired by Next.js.
• Axios: Handles HTTP requests to the Django backend and external APIs.
• React Native Reanimated + Gesture Handler: Supports smooth interactions and animations across views.
• React Native Picker: Enables selection inputs, used in task assignment flows.
• react-native-calendars: Used for visualizing garden tasks on a calendar interface.
• React Native Safe Area Context: Ensures layout compatibility across different device notches and insets.
• AsyncStorage: Persists authentication tokens securely on the device for session continuity.

Project Structure

The mobile project follows a modular screen-and-context-based architecture:

• /app: Contains Expo Router-based screen definitions, nested into domain folders (/auth, /tasks, /garden, /forum, etc.)
• /components: Shared UI components including WeatherWidget, TaskCard, GardenCard, etc.
• /contexts: Context providers such as AuthContext.tsx for managing authentication and global state.
• /constants: Defines configuration variables like API_URL, COLORS, and other shared constants.

Key Features and Components

1. Authentication Flow

• Implements JWT-based login and registration using React Context and AsyncStorage.
• reCAPTCHA integration ensures bot protection using a third-party CAPTCHA service.
• Session state is globally accessible through AuthContext, allowing auto-login and token-injected requests.

2. Task and Garden Management

• Users can view pending, in-progress, and completed tasks in separate sections.
• Workers can accept, decline, or complete tasks.
• Managers can assign tasks using a dropdown populated by accepted workers.
• Self-assignment feature implemented via a dedicated /self-assign/ backend endpoint for unassigned tasks.
• A tabbed garden view shows members, tasks, and a task calendar for each garden.
• Real-time state updates are triggered by action responses using useEffect and re-fetching logic.

3. Forum System

• Forum list and post detail screens allow users to read posts and view comment threads.
• Users can create comments on posts using authenticated POST requests.
• Navigation is handled via Expo Router’s useRouter() and useLocalSearchParams().

4. Weather Widget Integration

• The app uses Open-Meteo’s free API to fetch weather data based on the user’s profile location.
• WeatherWidget performs a 2-step fetch: geocoding to get lat/lon from city name, and then a weather request using those coordinates.
• Displays temperature, wind speed, humidity, and feels-like temperature inside a stylized card.
• Fully decoupled and reusable component integrated into the home screen.

5. Social Features

• Follow/unfollow and block/unblock functionalities are integrated with backend endpoints.
• Followers and following views are shown under the profile tab using FlatList.

UX & Styling

• All components follow a consistent color scheme defined in COLORS.ts.
• Layouts use Flexbox and responsive styles to adapt across screen sizes.
• UI elements like buttons, dropdowns, and cards are implemented using native components with custom styles.
• Feedback is given to the user using Alert.alert() for key interactions (e.g., task assignment, comment submission).

Testing & Debugging Strategy

• Manual testing was performed through Expo Go on both iOS and Android simulators.
• Navigation flows, API integrations, and state synchronization were validated across screens.
• Debugging was supported using Expo DevTools and React Native Dev Menu logging.

Backend Integration & API Design

• Backend communication is handled through axios with token headers injected from AuthContext.
• All authenticated views and task actions (assign, accept, decline, complete, self-assign) use secure backend endpoints.
• API calls use RESTful patterns, e.g., POST /tasks/{id}/accept/, POST /tasks/{id}/self-assign/.

Collaboration Workflow

• Şimal Güven implemented garden views, task management, self-assign logic, and weather API integration. She also contributed backend endpoints (self_assign, TaskViewSet filters).
• Eymen Çeliktürk led the initial mobile setup, auth system, and forum integration, and added follow/block features with backend support.
• Frequent PR reviews and code merges ensured consistency across components and logic layers.
• Context-based architecture enabled seamless collaboration and state management across multiple screens.

Member	Contribution
Ceylanberk Tola	Authored merge commits to integrate core features and enforce PR templates (merge commits #127 & #139); scaffolded the initial backend setup for the Django Project (PR #140); developed the profile struct and endpoints (PR #145; PR #146); designed and implemented Role-Based Access Control and garden management endpoints (PR #154); fixed incorrect response logic when fetching comments on a post (PR #176); added task-type features to the post model (PR #177); researched and implemented the external weather API integration in both backend and frontend (PR #178); opened and managed 31 issues to coordinate development tasks and resolve merge conflicts (e.g. issue #164); co-created the Project Requirements, driving initial SRS and terminology alignment (see the Project Requirements), updated all 10 Scenario pages in the project wiki based on feedback (issue #79); contributed to sequence and use-case diagram creation (issue #109) created meeting notes template (issue #8) and personal page template (issue #3) served as note-taker for Meeting Notes 4(issue #52) and reviewed multiple meeting notes e.g.(issue #45) ; supported backend teammates with debugging and endpoint design whenever they hit roadblocks; and consistently contributed to 7 of the 9 weekly meetings, driving communication and alignment across the team.
Suleyman Tolga Acar	* Created my personal wiki page. (Related issue: #6) * Established comprehensive Git Resources page with useful links to learn Git. (Related issue: #4) * Created Scenario 8 and reviewed Scenario 1, Scenario 2, and Scenario 3 * Participated in a dedicated class diagram meeting with @basak-tepe and @burakaltunay to plan the UML structure. Contributed to the UML Class Diagram by designing the User and Roles components. The completed diagram can be viewed here. (Related issue: #55) * Collaborated with @bahadirkuscan, @koybasimuhittin, @basak-tepe to research branch protection rules to restrict pushes to the main branch. (PR #65) * Updated and standardized all meeting notes for better organization. (Related issue: #80) * Enhanced the project Glossary by adding and updating terms to ensure consistent terminology usage throughout development. (Related issue: #113) * Reviewed and contributed to Sequence Diagram #3 and Sequence Diagram #4. (Related issues: #111 and #115) * Created comprehensive contribution guidelines to standardize development. (PR #120, related issue: #116) * Established the React application structure and configured essential development tools for the frontend project, created a prototype/template for the frontend providing a foundation for further development with basic routing and component structure. (PR #125, related issue: #124) * Designed standardized PR templates. (PR #127, related issue: #121) * Containerized frontend, backend and mobile projects using Docker and Docker Compose, configured PostgreSQL integration for the backend replacing the default database. (PR #147, related issues: #136 and #149) * Fixed authentication-related bugs in the frontend login/register pages, developed the user profile page with complete functionality for viewing and updating user information. (PR #153, related issue: #130) * Created comprehensive unit tests for both existing and newly added backend features including role-based access control mechanisms, and reviewed the PR using the unit tests and manual testing. (PR #154, related issue: #156) * Reviewed backend forum feature implementation, identified and reported a bug. (PR #161, related issue: #162) * Developed complete forum functionality for the frontend. (PR #169, related issue: #132) * Created a weather widget for the frontend that displays weather conditions for the user's location using external API integration. (PR #172, related issue: #165) * Replaced mock API calls with actual endpoint integrations throughout the frontend application, removed unnecessary features and placeholders that were out of scope for the current implementation. (PR #183) * Redesigned home page widgets for improved user experience and information display. (PR #183) * Fixed multiple breaking bugs and improved functionality in garden management and task features on the frontend. (PR #183) * Fixed and updated frontend test suites to accommodate the new API integrations and feature changes. (PR #183) * Created a new backend endpoint "/memberships/my-gardens" to fetch all gardens of a user. (PR #196, related issue: #195) * Fixed dependency conflict bug in the Docker containerization. (PR #147) * Enhanced forum display by changing user ID to username for better readability. (PR #200) * Collaborated with @eymenesad, @cberko, @bahadirkuscan to fix allowed hosts configuration bug for backend to enable proper API access. (PR #198) * Deployed the project with @eymenesad, @cberko, @bahadirkuscan on Digital Ocean, making it accessible at http://164.92.202.177/ * Recorded a comprehensive demo showcasing the frontend functionality and user flows, available here * Attended 6 out of 9 weekly team meetings along with several topic-specific meetings.
Bahadır Kuşcan	Created my personal wiki page to document weekly contributions (Issue #13), prepared elicitation questions for gathering initial project requirements and documented them in the team wiki (Issue #21), reviewed the project requirements for completeness and clarity (Issue #31), authored Scenario 6 and contributed to the requirements document accordingly (Issue #35), created the Glossary wiki page and updated project requirements (Issue #38), took notes for the customer meeting ensuring accurate documentation of feedback and requirements (Issue #43), revised Scenario 6 based on customer feedback (Issue #53), determined and drafted use cases relevant to core system functionalities (Issue #54), designed Use Case Diagrams #3 and #4 (these use cases later on merged to Use Case #3 and eventually all use cases merged to one) (Issue #60), tested and invalidated a GitHub Actions workflow to push restriction rules on the main branch (Issue #66, PR #65), initiated and participated in the general review and clean-up of the wiki (Issue #69), completed final revision of the project requirements (Issue #74) and contributed to class diagram revision (Issue #77), reviewed the backend setup and project structure (PR #140), implemented core backend authentication features including Login, Logout, Register, and Password Reset in Django REST Framework (Issue #129, PR #142, example implemented views), reviewed and conducted integration tests via Postman for Profile features (Issue #148, PR #146), reviewed and conducted integration tests and implemented unit tests for the External Weather API integration (Issue #179, PR #178), detected and fixed bugs in unit tests (Issue #181, PR #197), reviewed the project Dockerization (Issue #136, PR #147), reviewed the /my-gardens API endpoint implementation (Issue #195, PR #196), updated the project README for onboarding documentation (PR #199), reviewed a final frontend bug fix (PR #200), collaborated on project deployment and provided solutions to issues encountered, such as specifying the correct host IP address in several parts of the code (Issue #137, PR #192). Attended 7 out of 9 weekly team meetings along with several impromptu meetings.
Şimal Güven	* Created a personal wiki page (Issue #11) * Added a glossary to requirements (Issue #30) * Authored (Scenario 7), and reviewed multiple other scenarios. * Designed use case diagram #1 with @koybasimuhittin (Issue #62) * Reviewed created review issue template (Issue #49) * Merged use case diagrams into lucidchart (Issue #76) * Designed sequence diagram #1 (Issue #81 ,Issue #104) * Reviewed sequence diagram #2 (Issue #110) * Designed sequence diagram #3 (Issue #81,Issue #106) * After first implementation issues were distributed, started learning React native * Reviewed Create Auth and Profile pages for frontend (PR #153) * Reviewed feature/133-login-register-mobile (PR #171) * Started Garden mobile implementation with integrating captcha into login-register feature (PR #175) * Written task view and gardenmembership view API endpoints in order to continue mobil dev (PR #175) * Started feature/173-garden-mobile (PR #175) * Reviewed feature/135-forum-mobile (PR #180) * Completed feature/173-garden-mobile, solved merge conflicts, merged (Issue #173,PR #175) * Completed feature/182 weather api mobile, created a PR, merged (Issue #182,PR #188) * Completed feature/189 self assigning a task, created a PR, merged (Issue #189,PR #191) * Reviewed Bug/184 follow mechanism mobile (PR #185) * Reviewed feature/187-block-unblock, detected a bug asked for a fix (PR #193) * Reviewed PR Added "my-gardens" endpoint to Backend (PR #196) * Attended 8 out of 9 group meetings, taken notes in 2 of them. Attended customer meeting.
Eymen Çeliktürk	* Set up the mobile app scaffold and CI pipeline (PR #141, issue #134). * Developed mobile login, registration, and user–profile flows with CAPTCHA integration calling the external API (PR #171, issue #133). * Implemented the mobile forum interface and data sync (PR #180, issue #135). * Added follow/unfollow interactions in the app (PR #185, issue #184). * Built block/unblock user functionality end-to-end, including the new backend endpoints (PR #193, issue #187). * Deployed the mobile release by merging into main for the final demo (PR #192). * Reviewed teammates’ mobile PRs (#175, #188, #191) and provided feedback on key backend/frontend merges (#140, #142, #146, #147, #169, #183, #197). * Participated in defining and refining the use-case diagrams and related design discussions (issues #15, #24, #61, #63, #138). Attended 8 out of 9 group meetings, taken notes in 2 of them. Attended customer meeting.
Başak Tepe	Issues I contributed to: - #23, Drafting out the requirements - #48 and #71, Creating a review issue template - #55, Creating class diagrams - #69, General Review during design phase - #73, Updating requirements with moodle feedback - #75, Updating class diagrams with moodle feedback - #76, Updating use case diagrams with moodle feedback - #77, Reviewing class diagrams - #83, Reviewing use case diagrams - #95, #96, #97, #98, #99, #112 Reviewing scenarios 1-6 - #105, Creating sequence diagram 2 - #107, Creating sequence diagram 4 - #114, Reviewing the glossary - #130, Implementing login and register related pages - #163, Minor bug fix about login - #167, #168 Implementing garden and task related pages My pull requests: - #47, Review issue template - #70, Updated review issue template - #166, Login-Register, API Call, and Backend Integration - #183, Gardens & Tasks In terms of implementation, I mostly contributed to the front-end of our project. My implemented API call is Google Recaptcha, and backend contributions are in #166. (A LoginWithCaptchaSerializer function, some serializer & view updates.) I attended classes as much as I could, 8 out of 9 group meetings, the customer meeting, and I was the note taker in 3 of them.
Burak Altunay	* Created a personal wiki page. * Reviewed elicitation questions, related issue: #26. * Created a scenario. * Attended customer meeting, related issue: #41. * Moderated and reviwed weekly meeting 4, related issue: #51. * Participated in a dedicated class diagram meeting to plan the UML structure. The completed diagram can be viewed here, related issue: #55. * Pushed restrictions to main with a workflow, related issue: #66. * Updated scenarios 6-10 based on moodle feedback, related issue: #82. * Taken notes of weekly meeting 6 , related issue: #108. * Deployed the project for the feedback, related issue: #137. * Attended 9 out of 9 weekly team meetings along with several topic-specific meetings.

Throughout the development of our project, we utilized a variety of tools and workflows to manage the team project effectively. GitHub Projects and Issues played a central role in tracking progress and assigning tasks. Each feature or bug fix was linked to an issue, and we used pull requests (PRs) combined with code reviews to ensure code quality and team alignment. Pull requests were tested both manually and with unit tests before merging. The GitHub Wiki served as a shared knowledge base for documenting meeting notes, project requirements, scenarios, diagrams and much more general information about the project, which helped maintain consistency.

For communication, we primarily used a WhatsApp group chat for real-time updates and quick questions, alongside Google Meet for scheduled weekly meetings. Task planning, progress updates, and integration discussions were handled in these online meetings, which helped maintain clarity on priorities and ensured alignment across team members.

We used Lucidchart and Mermaid.js to create class, use-case and sequence diagrams. We chose Mermaid.js at first but then we couldn't find a suitable graph type for use-case and sequence diagrams. So, we used Mermaid.js for the class diagram and used Lucidcharts for the others for more customizable graphs. Postman was a valuable tool for API testing and debugging during backend integration, and Docker helped standardize development and deployment environments across team members.

We chose Django with PostgreSQL for the backend, taking advantage of their strong integration to simplify data modeling and API development. Django’s built-in admin interface and ORM accelerated backend progress and reduced boilerplate, allowing us to focus more on application logic and API design. For the frontend, we used React, and for the mobile app, we used React Native. Since they have similar syntax and principles, this enabled us to share some common knowledge between the web and mobile applications, which was beneficial for our team.

Deployment was handled manually by connecting to a DigitalOcean droplet. While we did not implement a full CI/CD pipeline, this deployment method gave us practical experience managing production environments.

On the testing side, we made an effort to write unit tests for our functions and ensure PRs passed both unit tests and manual testing. We also took feedback seriously, often revisiting and refining documentation, diagrams and features based on suggestions.

Overall, our toolset was effective in supporting collaboration and project management for a multi-platform application. GitHub Projects and PR-based workflows gave us structure, while Postman, Docker, and diagramming tools improved integration and development speed. Communication tools enabled us to coordinate well as a distributed team.

However, some areas could be improved. Not all tasks had clearly defined deadlines or owners, which led to occasional delays or confusion. In future projects, introducing more structured planning such as weekly sprints or clearer ownership tracking would improve accountability and pace. Although unit testing helped us catch bugs early, coverage varied across modules, a more consistent testing approach or the addition of lightweight CI automation would improve long-term maintainability and confidence in our code.

Although we benefited from using React and React Native in parallel, we didn’t fully leverage the potential for shared code or design reuse between the web and mobile apps. In future projects, we would explore strategies for sharing logic, styles, or UI components across platforms to improve development efficiency and reduce maintenance overhead.

Manual deployment worked for this project but could become a bottleneck in larger teams or more frequent update cycles. Setting up basic CI/CD tooling in future projects would streamline this and reduce potential deployment errors.

In summary, while our tools and processes served us well overall, we identified key improvements such as stronger task management, more consistent testing, and automated deployment that we would carry forward into future projects to enhance team efficiency and software quality.