Overall I think our problem research, definition, and validation were thorough and effective for the time. The team spent weeks brainstorming possible ideas in order to find the right one. Because of this delay, the team switched problems after Element A, as the original problem, regarding that of solar panels, was found to be weak and impractical. If the project were to be redone, the team would likely have sought to use more decisive means of finding and determining a problem in order to more effectively spend time. However, switching problems, in the beginning, was a valuable learning experience as the team sought to plan ahead and understand the problem to the furthest extent.

In terms of article research, this was mainly done in an effort to effectively validate the problem we determined previously. These efforts were completed mainly in Element A, as the team sought to figure out and determine a problem that they could solve, switching from solar to procrastination. During such research, the team compiled lists and information surrounding the problem of procrastination, specifically in students, through scholarly essays and other public articles. This process could have been improved if the team had created a better plan to cohesively work together in order to find optimal articles and compile the information. This would have increased efficiency significantly, and the value of the information. However, the research information acquired in this section was essential to the growth and development of profectly as a product, especially in the design and prototyping stages.

The solution research was done in order to effectively determine the competition and its varying pros and cons. By understanding these factors the team was able to determine areas, where there was potential for innovation in the market, and such could be exemplified in the designs and prototypes. Furthermore, for this area of work, market analysis was performed to determine the economic environment that Profectly would face. By optimally listing and compiling similar solution data as a team, the foundation was built for the future designs and prototypes to be built off of. However, this process could have been improved by researching a further spread of competitor solutions and then going into a deep dive on a few key ones in order to gain a better understanding of the depth of the market.

Designing and planning such design for the prototypes was a fundamental component of the Profectly project. Using both the objectives concluded through the problem statement and user stories, as well as the potential solutions, the team created an assortment of the possible website or app designs for the 1st prototype. In the future, if this were to be redone, the team would likely have done this process in a way that would be better suited for app and web design because the methods used were ill-equipped for such. This would allow for a wider range of optimal designs that would work well alongside one another instead of individually. This hurt in terms of selection because the team designs were based off of individual menus rather than a collection so for the first prototype the three best were selected, but this didn't mean they were optimal for one another. The decision regarding the menu designs to use was determined via the Decision Matrix. This was quite effective at determining a solid design, but could use some optimization next time by the team in order to include a collection of menu designs that would fit with one another.

Through the agile methodology, the team effectively determined requirements for the prototypes and prepare them for finality. The key aspects of such that were exemplified the most were the planning, development, design, testing, and feedback stages. These various aspects were highlighted throughout the project. The stages for planning, design, and feedback provided the most information and development regarding the creation and implication of requirements for the prototype. However, in the future, the team would like to incorporate the release factor of the project, as this would allow for more development and constructive feedback. This wouldn't be as difficult for software as well because manufacture is essentially putting the app on the Google or Apple app store.

The development of the prototype and testing was an essential component of the development of the project, especially in the latter portion. For prototyping, there were two front-end prototypes made to demonstrate the potential for the app in regards to visuals, streamlining the user experience, and illustrating the potential functionality that could be implemented into the prototypes. The third prototype sought to create an effective back-end with little bugs that could demonstrate the functional potential alongside prototype #2. However, making the prototypes in two different portions (front-end and back-end) lead to a lacking final result that would have little viability on its own. Therefore, if this were to be redone, there should be a prototype that encompasses both a solid front-end and back-end all in one, and includes various tools in order to increase the optimization and viability for the user. Testing such prototypes was done in the form of qualitative testing, which obtained feedback and data directly from the user, as well as quantitative testing which used the user stories from Element C as criteria to define the successes and failures of each prototype. Although the quantitative was relatively effective at enforcing the points made in the qualitative testing, it didn't provide any unique new data. So if this were to be redone, the team would likely choose a better method of quantitative testing for the prototypes in order to obtain more insightful data.

STEM application for the project came mainly in the form of data collection, engineering principles exemplified in the prototypes, and qualitative and quantitative testing. More specifically, through code, design principles, and testing, the Profectly project was completed to a considerable extent in regards to scientific, engineering, and mathematic principles, especially with that of the prototyping. However, if this were to be redone, the team would likely try to implement more aspects of engineering especially with the combination of front-end and back-end prototypes, because there was too much time spent on front-end prototypes, which provided only so much benefit to the project.