A record of building the foundation: from ideation and prototyping to navigating senior feedback and implementing the MVP
The password you enter is used to open, edit, and delete secret comments.
No comments yet.
링크 정보를 불러오는 중...
The weekend of the third week of the group project is coming to an end. Originally, I planned to write a final retrospective after the project was over, but I've gained so much insight from other campers sharing their weekly reflections that I decided to leave a mid-term retrospective of my own.
So far, the project has progressed as follows:
On the first day, we took time to introduce ourselves. We created the repository and did the basic setup, but since there were other sessions during the day, we focused on light greetings and general direction rather than deep discussions, deciding to finalize the topic the next day.
We shared our prepared ideas and shortlisted candidates. I had prepared about four ideas, but most were ambiguous for reasons like:
As there are already so many great services out there, I realized that choosing a project topic is becoming increasingly difficult.
What I wanted for this period was to create a meaningful service with real users, but more importantly, to experience a project where I could try something more challenging. I didn't want a project that just ended after implementation without meaning; I wanted a direction that satisfied both.
Only one of my initial ideas met these conditions. While the theme and scalability were good, I worried it was too simple for our team's capabilities to spend over a month on. Then, during a break, a new idea struck me, and the teammates reacted positively.
Referencing two apps I frequently use, I recombined keywords and contexts to fit our situation. Based on that, we expanded and organized the idea according to the provided sprint materials and finalized the topic.
While not a completely groundbreaking service, it was a choice that aligned with each member's goals and direction, and ultimately, everyone was satisfied.
링크 정보를 불러오는 중...
On the second and third days, we focused on defining conventions. Based on the methods used in previous sprint teams and the pros and cons I felt then, I drafted a proposal which we refined together.
We organized this in the Wiki, and I feel that managing team documents through the Wiki from the first week was an excellent choice. We also finalized the basic project setup and introduced Husky this time to automate convention checks and lint checks before PRs. It was quite an effective move for maintaining code quality across the team.
Based on our planning document, we had a demo and feedback session with other teams. Other campers provided active feedback, allowing us to re-examine user perspectives and directions we hadn't considered.
Personally, I thought I had targeted the audience well, but looking at it from a real user's perspective, I realized there was a lot of room to narrow the target further and ensure scalability. This was a very meaningful session.
Pros:
Cons:
In Week 2, I focused on implementing the prototype based on the design I created and worked on organizing our plans into a single document ahead of the senior feedback session.
During the design process, I used Figma Make for the first time, and I was surprised by the quality. In previous projects, I designed every screen manually, but Make produced results well-divided into React and Tailwind-based structures.
I briefly thought, "Is a frontend developer even necessary?" However, for parts that weren't implemented as desired, I first established a visual guide with Gemini, passed it through Figma Make, and then refined it myself.
Since this was the prototyping stage, I used Cursor AI to quickly implement basic screens. Although low-quality pages needed individual refinement later, it was a very efficient experience in terms of turning ideas into a visible form quickly.
This week, we had our first offline meeting. Having been used to online collaboration, I hadn't felt a strong need for offline work, but I realized that a task that might take 5 hours online could be finished in 2 hours offline. The focus and speed were definitely different.
In particular, having a teammate who excels at organizing functional requirements and user flows allowed us to structure ideas much more clearly.
The core of the senior feedback at the end of the week was: "The overall plan is still vague."
We thought we had discussed enough, but it turned out that each member's priorities, desired implementation directions, and perceived importance were different. I felt a sense of crisis that our direction could easily scatter if we continued like this.
Up until then, we were focusing on raising the quality of CS quizzes and implementing basic pages (Main, Quiz, Explanation, My Page, Settings, etc.). We believed that the quality of questions was directly linked to the service's credibility in the CS domain, and that pages handling user info were essential for a personalized learning experience. Thus, we prioritized features based on "things that should be made first."
However, the senior looked at our plan and said:
"It looks like you're taking the easy way out by only choosing things you can easily implement."
This didn't mean we shouldn't make basic features, but rather that the elements we were focusing on didn't differentiate us from existing CS quiz services and might look like a low-challenge level for the team's capabilities.
Honestly, this was something I had been contemplating as well. I kept asking myself if we were just filling the project with easy features and if this choice utilized the team's full potential.
In this context, the senior advised us to think about the "Wow Point" that could make the service attractive and technically challenging, even if it wasn't a "must-have" core feature.
The senior's remark that it's better to implement technically challenging parts early while energy is high and then upgrade them through user testing was impressive. We realized that features like "My Page" or "Settings" could be made later; it's better to prioritize challenges over mere completion.
Naturally, the question "Technical challenge vs. Service meaning?" arose, and the conclusion was not to choose one but to find a point that is both necessary for the service and technically challenging.
Personally, I kept thinking that utilizing characters could be that point. Since design and characters are meaningful fields to me, I had the ambition, but I was hesitating because I wasn't sure if investing time there would be meaningful for the project.
Fortunately, during the senior feedback, I heard that if it's an element we want to use as a differentiator, it's worth implementing, and in fact, we should actively utilize it. Even if characters aren't a core functional requirement, they were judged as meaningful devices to differentiate the service and raise the team's challenge level.
Ultimately, I understood the message as: don't stay stuck in basic implementations that make the service look like everything else; reveal the "Wow Point" first and build features on top of it. However, we moved into the intermission without a concrete conclusion on whether to go with 2D or 3D characters.
Pros:
Cons:
I couldn't secure as much time as I expected during the intermission due to various appointments. It was difficult to study deeply.
Nevertheless, I luckily had a chance to take a Three.js lecture. Implementing what I used to only see in Blender through code was a very fresh experience. Since it's my area of responsibility, I invested time to implement 2D and 3D characters, at least in some form, to show the team.
Looking at Slack, many teams formed study groups even during the intermission to study and present. Seeing that made me realize how lucky I am to be in this camp and motivated me to work harder. As the camp's conclusion approaches, I've had many personal thoughts about what kind of environment I should create to study more deeply in the future.
At the start of Week 3, we needed some warm-up time after being away. We re-established the project direction by synthesizing previous feedback and clearly prioritized the ideas we selected.
Personally, I suggested organizing things like the reward system—even if not needed for immediate implementation—so that all team members share the same understanding of the service structure. Fortunately, we reached a consensus, and it was a very meaningful discussion.
Since I was always frustrated that meeting discussions weren't properly recorded, I introduced a method of organizing Slack Huddle scripts for the first time. Having records made it much easier to track the context of previous discussions.
After that, we finalized priorities based on the MVP scope and spent two days implementing them quickly. It was a new and interesting experience to actively use testing and Storybook in a project for the first time.
Personally, I realized again that the amount of commits in a single PR is too large. I kept repeating the mistake of bundling refactoring and minor fixes from other areas into one PR. While my ability to split commits has improved, I still lack the ability to make a single PR concise and aligned with a clear purpose.
I also struggle with what unit to divide issues into. For example, when multiple components need to be created in one issue, there's a dilemma: splitting them breaks the context, but merging them makes the PR too large. I want to see and learn how others solve this.
This week, we integrated the frontend and backend and proceeded with deployment on the last day. However, more issues than expected occurred right before the demo, and we had to continue working until 1 minute before the start.
As a result, I was more nervous than ever during the demo, and the presentation was very unsatisfying. I wanted to show my best since many people I know were watching, so the disappointment was huge. I was flustered by a screen issue in the middle, and the overall flow wasn't smooth. It was very, very regrettable.
In the coming weeks, I definitely want to improve the following:
Also, after passing through these 3 weeks, new questions have arisen:
Since I have experienced a previous team project falling through in the middle, I want to experience a single, complete result this time. I want to organize these thoughts well and create a more meaningful team collaboration for the remaining period.
