Project Retrospective

Project Retrospective

1. Context & Scope

Genipe (Cross-Generational Recipe & Food Heritage Platform) is a collaborative web and mobile platform for preserving culinary traditions. Users can document family recipes, share cultural stories tied to meals, and connect across generations through food heritage.

This retrospective covers the MVP period (Milestones 1–3), delivered on April 7, 2026. The MVP included user authentication, recipe and story CRUD, search and filtering, ingredient/unit management, and full deployment across all three client surfaces (web, mobile, backend API) at genipe.app.

For project status, deliverables, and requirements coverage, see the D6 Milestone Review.

2. Methodology

This retrospective was compiled asynchronously from five input sources:

1. D6 Milestone Review — project status, deliverables, testing, team process evaluation
2. D7 Individual Contributions — per-member self-assessments
3. Responsibility Assignment Matrix (RAM) — issue/PR assignee, reviewer, and informed data
4. Instructor demo feedback — live feedback received during the MVP demo session
5. Team meetings after demo session and during Lab 8 - meetings where the situation is assessed, and individual feedback is discussed.

Each item is evaluated along the three dimensions required by the course: activities, decisions, and managerial practices, and classified as either positive (Went Well) or negative/unexpected (Went Badly / Unexpected), along with its impact on the project development lifecycle.

---

3. What Went Well

3.1 Activities

Milestone decomposition into tracked issues
Issues #140, #142, and #167 converted each milestone into concrete, assignable GitHub issues with clear ownership. This positively impacted the lifecycle by providing
end-to-end traceability from requirement to PR.

Demo rehearsal caught pre-demo bugs
Issue #173 (MVP Demo Preparation & Rehearsal) identified 6+ frontend bugs before the live demo, including the critical author-ID type mismatch (#322). This positively impacted the lifecycle by preventing visible failures during the instructor demo.

Database seeding via migrations
PRs #283 and #292 seeded 31 world cuisine regions, and approved ingredient/unit sets via data migrations. This positively impacted the lifecycle by enabling a fully functional demo with realistic content.

Independent mobile development reached feature parity with web
The mobile team (Mustafa Ocak, Mustafa Çağan İslam) built and shipped full feature parity with the web client across all three milestones independently, with 39 merged PRs. This positively impacted the lifecycle by ensuring all three client surfaces were demo-ready simultaneously.

Backend test coverage
76 test methods across 4 modules (users: 27, recipes: 21, stories: 17, search: 11) were written and run in CI on every PR. This positively impacted the lifecycle by keeping the API stable throughout the sprint and catching permission/validation edge cases early.

3.2 Decisions

Monorepo structure
Choosing a single repository with app/backend, app/frontend, and app/mobile directories positively impacted the lifecycle by simplifying cross-team issue linking, shared CI configuration, and a single source of truth for all three surfaces.

DRF + JWT + PostgreSQL stack
The backend technology choice (Django REST Framework, djangorestframework-simplejwt, PostgreSQL) was stable throughout the MVP. Zero backend authentication bugs were reported in production, which positively impacted the lifecycle by eliminating a common source of integration failures.

React (Vite) + React Native (Expo)
Sharing the same paradigm (React) between web and mobile enabled a shared mental model and rapid knowledge transfer between subgroups, positively impacting the lifecycle by reducing ramp-up time when members moved between client surfaces.

Full deployment before demo
Deciding to deploy all three surfaces (Vultr VPS + Vercel + EAS, Nginx + SSL at genipe.app) before the demo — rather than demoing locally — positively impacted the lifecycle by validating the complete production environment and eliminating "works on my machine" scenarios.

3.3 Managerial Practices

Explicit Responsibility Assignment Matrix
The RAM (#266, #197) documented assignee, reviewer, and informed parties for every issue and PR. This positively impacted the lifecycle by making ownership unambiguous and enabling structured code review.

Backend/frontend subgroup split
Dividing the team into a backend subgroup (Ahmet Akdağ, Uygar Apan, Ahmet Ayberk Durak, Emirhan Şimşek, Ufuk Altunbulak) and a frontend/mobile subgroup (Eren Can Özkaya, Mustafa Ocak, Mustafa Çağan İslam, Dağlar Tekşen) enabled parallel progress across all three milestones, positively impacting the lifecycle by preventing bottlenecks.

Final-sprint bug triage
11+ bugs were identified and fixed in a two-day sprint immediately before the demo. Ahmet Akdağ systematically tracked these as issues, and Mustafa Çağan İslam, Eren Can Özkaya, and Mustafa Ocak resolved them. This positively impacted the lifecycle by converting a potentially failed demo into a stable delivery.

---

4. What Went Badly / Unexpected

4.1 Activities

Frontend-backend contract not defined early
The frontend was built against assumed payload shapes rather than a shared contract with the backend. This produced avoidable payload format mismatches (#279, #282, #277) that
surfaced only in the final integration sprint. This negatively impacted the lifecycle by compressing bug-fix time and introducing risk immediately before the demo.

Integration testing delayed until demo week
Backend and frontend were tested in isolation (backend via APITestCase, frontend via mocked API calls) throughout the MVP. Cross-layer integration was not validated until demo rehearsal. This negatively impacted the lifecycle by concentrating risk at the worst possible moment.

No automated mobile test suite
The mobile app (React Native) shipped with manual testing only — no Jest or React Native Testing Library tests. This negatively impacted the lifecycle by leaving regression risk undetected across 39 merged PRs.

Mobile connected to production API only in the last week
PR #303 connected the mobile app to the production API in the final week before demo. All prior mobile development was tested against local/mock data. This negatively impacted the lifecycle by delaying the discovery of mobile-specific integration issues.

4.2 Decisions

Recipe-first product framing
The platform was designed and built with recipes as the primary content type. The instructor's demo feedback identified this as the most significant strategic misalignment of the MVP: the platform's identity should be built around cultural heritage and traditions, with recipes serving as one medium among many. This framing decision was made in M1 planning and shaped all subsequent UI/UX, data
models, and navigation. It negatively impacted the lifecycle by requiring a fundamental redesign of the home page, data model, and discovery system for M4–M6.

Narrow target audience assumption
The UI/UX was implicitly designed around elderly content creators. The instructor's feedback highlighted that the platform should appeal to all ages and cultural backgrounds on both the creator and consumer sides. This negatively impacted the lifecycle by narrowing design choices that now need revisiting.

No shared API schema artifact
The team did not produce an OpenAPI schema or shared type definitions before parallel implementation began. Each subgroup made independent assumptions about payload structure. This negatively impacted the lifecycle by making payload mismatches inevitable and undetectable until runtime.

4.3 Managerial Practices

Product vision not validated after Milestone 1 The team did not seek an instructor check-in on product direction after completing the first milestone. The vision misalignment was only discovered at the final MVP demo. This negatively impacted the lifecycle by allowing seven weeks of implementation to proceed in a direction that required fundamental course correction.

Cross-team sync was ad hoc, not scheduled
Backend and frontend subgroups communicated on-demand rather than on a fixed cadence. This negatively impacted the lifecycle by allowing payload assumptions to diverge silently and reducing the team's shared understanding of integration state.

Reviewer load was unevenly distributed
RAM analysis shows that the top 3 reviewers (Mustafa Çağan İslam, Eren Can Özkaya, Dağlar Tekşen) handled approximately 77% of all PR reviews in the MVP phase. This negatively impacted the lifecycle by creating review bottlenecks and reducing cross-subgroup knowledge transfer.

4.4 Unexpected Events

Instructor reframed the product vision at the demo
The instructor's feedback at the MVP demo was a fundamental reframing: cultural events and traditions should be the entry point, not recipes. This was unexpected in its scope — not a feature request, but a directional pivot that affects the home page, data model, and search system.

Author-ID type mismatch bug caught at rehearsal
Issue #322: the story edit authorization check compared an integer user ID (from the JWT) against a string (from the API response), silently failing the ownership guard. This was caught during demo rehearsal and fixed before the live demo. It was an unexpected class of bug — correct logic, wrong types — made possible by the absence of shared
type contracts.

Mobile team reached feature parity faster than expected (positive)
The mobile team independently shipped full feature parity with the web frontend across all three milestones, including a CI pipeline for APK generation (PR #256). This unexpectedly and positively affected the lifecycle by giving the team a fully functional third surface at demo time with no additional
coordination cost.

---

5. Key Metrics

Delivery

Metric	Value
MVP deliverables completed	11 / 11
Backend endpoints	20+
Backend test methods	76 (4 modules)
Frontend test cases	182 (24 files)
Mobile automated tests	0
Bugs fixed in final 2-day sprint	11+
Open bugs at demo	1 (#322, fixed post-demo)
Merged PRs (MVP phase)	100+

Contribution Distribution

Member	Role	Notable PRs	Key Issues
Ahmet Akdağ	Backend + DevOps	#268 #269 #271 #283 #287	#148 #156 #195
Eren Can Özkaya	Frontend Web	#200 #201 #228 #288	#194 #152 #170
Mustafa Ocak	Mobile + DevOps	#199 #236 #256 #303	#192 #158 #170
Mustafa Çağan İslam	Frontend Web + Integration	#284 #285 #286 #292	#279 #282 #276
Dağlar Tekşen	Frontend Web	#257 #258 #259 #261	#152 #175
Ufuk Altunbulak	Backend	—	#149 #156 #169
Ahmet Ayberk Durak	Backend	#270 #272	#143 #144 #161
Emirhan Şimşek	Backend + DevOps	—	#178 #180 #157
Uygar Apan	Backend	#233 #235 #242 #249 #250	#149 #151 #157

RAM Observations

• Reviewer concentration: The top 3 reviewers (Mustafa Çağan İslam, Eren Can Özkaya, Dağlar Tekşen) accounted for approximately 77% of all PR reviews in the MVP phase.
• Cross-subgroup review: Backend PRs were reviewed only within the backend subgroup, and frontend/mobile PRs only within the frontend/mobile subgroup. Cross-subgroup review was minimal, representing a missed knowledge-sharing opportunity.
• Highest commit volume: Eren Can Özkaya (106 commits), Mustafa Ocak (39 merged PRs).

---

6. Individual Reflections

Ahmet Akdağ — Backend + DevOps

• Went well: Delivered the entire backend infrastructure — API, deployment (Vultr, Nginx, SSL, genipe.app), CI/CD (PR #287), media storage (PR
  #269), and database seeding (PR #283) — enabling all three clients to demo against a stable production environment.
• Went badly: Acting as the integration bridge between frontend and backend (tracking 11+ bugs during integration testing) revealed that earlier cross-team contract alignment would have prevented most of these issues.
• Personal takeaway: For M4–M6, publish an OpenAPI schema before frontend implementation begins, and run integration checks weekly rather than only in the final sprint.

---

Eren Can Özkaya — Frontend Web

• Went well: Delivered the full web frontend across M1–M3 (PRs #200, #201,
  #228, #288) with 182 frontend tests and rapid triage of integration bugs (#304, #316, #323).
• Went badly: The frontend was built against assumed payload shapes rather than a contract with the backend, producing avoidable bugs (#279, #282, #277) in the final sprint.
• Personal takeaway: For M4–M6, define API contracts collaboratively before frontend implementation and add integration tests between layers.

---

Mustafa Ocak — Mobile + DevOps

• Went well: Delivered full feature parity with the web frontend independently across all three milestones (39 merged PRs), including CI for APK builds (PR
  #256) — an outcome that exceeded expectations.
• Went badly: Connecting the mobile app to production only in the last week (PR #303) compressed the window for finding mobile-specific
  integration issues.
• Personal takeaway: For M4–M6, connect mobile to the production API from the beginning of each milestone, and add an automated test suite to protect the feature surface built in M1–M3.

---

Mustafa Çağan İslam — Frontend Web + Integration

• Went well: Played a critical stabilization role in the final sprint — fixed recipe creation (#284), search display
  (#285), story author name (#286), and seeded the ingredient/unit database (#292) without which the demo would have been non-functional.
• Went badly: Most of the bugs fixed in the final sprint were consequences of assumptions made weeks earlier without cross-team verification.
• Personal takeaway: For M4–M6, run a shared integration checklist against the production API at the end of each milestone, not only before the demo.

---

Dağlar Tekşen — Frontend Web

• Went well: Delivered the mock data layer (PR #261) that unblocked frontend development while the backend was not yet ready, and fixed session persistence on page refresh (PR #257) — a core UX issue.
• Went badly: The mock data layer, while useful for development, implicitly encouraged building against assumed payload shapes that diverged from actual API responses.
• Personal takeaway: For M4–M6, wire mock data to a shared contract (e.g., OpenAPI) so that mock and production payloads stay synchronized.

---

Ufuk Altunbulak — Backend

• Went well: Contributed to all core backend features (auth, recipes, stories, search) consistently across the three milestones as part of a reliable backend subgroup.
• Went badly: Backend contributions were not visible as standalone PRs, reducing the traceability of individual impact in the RAM.
• Personal takeaway: For M4–M6, open focused PRs per feature to improve traceability and enable more granular code review feedback.

---

Ahmet Ayberk Durak — Backend

• Went well: Delivered the lookup APIs (PR #270) and custom submission API (PR #272)
  that enabled frontend dropdowns — a dependency that would have blocked recipe creation without timely delivery.
• Went badly: The lookup API design was not communicated to the frontend as a contract, requiring the frontend to discover the payload format through trial and error.
• Personal takeaway: For M4–M6, document every new API endpoint in a shared format immediately upon implementation.

---

Emirhan Şimşek — Backend + DevOps

• Went well: Published the backend development plan wiki page and set up the test database seed script (#178), establishing development
  infrastructure that the whole backend subgroup relied on.
• Went badly: Created the RAM template (#197) but reviewer load was not actively monitored or balanced throughout the MVP.
• Personal takeaway: For M4–M6, use the RAM not only as a record but as an active tool for balancing workload and reviewer assignments at the start of each milestone.

---

Uygar Apan — Backend

• Went well: Delivered the authentication foundation — Django project initialization (PR #233), auth API endpoints (PR
  #235), and endpoint protection middleware (PR #249) — which all subsequent backend and frontend features depended on.
• Went badly: JWT middleware was implemented without logging, making it difficult to diagnose authentication failures during integration testing.
• Personal takeaway: For M4–M6, add structured logging to all security-critical middleware from day one to accelerate integration debugging.

---

7. Lessons Learned

1. Validate product vision with stakeholders after every milestone, not only at the demo. The most expensive surprise in M1–M3 was a vision misalignment that seven weeks of implementation made harder to correct. A structured check-in after M1 would have surfaced this at a fraction of the cost.

2. Define cross-layer contracts (API schema) as a first-class artifact before parallel implementation begins. Three payload-mismatch bugs
   (#279, #282, #277) were not bugs in logic — they were the predictable result of two teams making independent assumptions about the same interface.

3. Integration testing must begin when two layers are both "ready enough," not at demo week. Compressed integration windows create regressions, raise stress, and reduce demo quality. Integration should be a continuous activity, not a phase.

4. Automated testing should cover all client surfaces from the beginning. The mobile app shipped 39 PRs with zero automated tests. Feature parity without test coverage is a hidden risk that compounds
   with each milestone.

5. Connect all clients to the production API from the start of each milestone. Developing mobile against mock or local data while the backend is live creates a false sense of completion and delays real integration feedback.

6. The RAM is descriptive by default — reviewer load must be actively managed. Recording ownership is not enough; reviewer assignments should be checked and balanced at the start of each milestone to
   prevent concentration and improve cross-subgroup knowledge sharing.

7. Independent subgroup progress is valuable but requires scheduled sync points. The backend and frontend subgroups both made strong individual progress. The gaps appeared at the boundaries — where
   payload shapes, field names, and data types were assumed rather than agreed.

---

8. Action Items for Milestones 4–6

#	Action	Owner	Due	Success Criterion
A1	Redesign home page around cultural events, not recipe listings	Frontend Web + Mobile	M4	Home page surfaces events/stories as primary entry point
A2	Introduce CulturalEvent model linking recipes & stories	Backend	M4	Migration merged; API endpoints live
A3	Publish OpenAPI schema; frontends consume agreed payload types	Backend + all frontends	M4 (early)	Zero payload-mismatch bugs in M4
A4	Add automated mobile tests (Jest + React Native Testing Library)	Mobile	M4	≥30 tests; CI runs on PR
A5	Connect mobile to production API from day one of each milestone	Mobile	M4+	No mock-only development windows
A6	Weekly backend↔frontend cross-subgroup sync (30 min)	All	M4+	Meeting notes published in wiki
A7	Instructor vision check-in at end of each milestone	Team (Mustafa Ocak)	M4, M5, M6	Written confirmation in wiki
A8	Expand filtering system: life events, religious occasions, seasonal	Backend + Frontend	M5	Filter taxonomy documented and implemented
A9	Broaden UI/UX for all age groups	Web + Mobile	M5	Design review wiki page published
A10	Rebalance PR reviewer assignments via updated RAM	All	M4 start	No single reviewer handles >30% of PRs in a milestone

Each action item above will be opened as a GitHub issue and linked to this page.

---

9. References

• Milestone Review
• Responsibility Assignment Matrix
• Repository
• Deployed App

---