\section{Discussion}

The development of Study Sprint shows both the strengths and limitations of building a small productivity application around one tightly scoped user problem. The project did not aim to compete with broad commercial productivity platforms on feature count. Instead, it aimed to reduce the gap between planning study work and actually starting it. In that sense, the most important question is not whether the app includes many features, but whether the implemented features support one coherent and dependable study flow.

\vspace{2mm}

Overall, the final result suggests that the project moved substantially closer to that goal over time. The strongest improvement was not the addition of one isolated feature, but the gradual alignment between planning structure, timer behaviour, session persistence, progress visibility, and onboarding. Earlier versions of the app already contained the core building blocks, but later revisions made those parts reflect the original product direction more clearly and work more convincingly as one product rather than as loosely connected components.

\subsection{Strength of the Hierarchy-Driven Product Model}

One of the clearest lessons from the project was that the application's underlying hierarchy mattered more than first assumed. The conceptual model of \textit{Subject $\rightarrow$ Assignment $\rightarrow$ Task} was not only a database relationship but also an important usability principle. When assignments and tasks were exposed too much as standalone top-level concepts, the app became flatter, more repetitive, and less clear. Important context was lost, and the user could more easily lose track of what a specific task belonged to.

\vspace{2mm}

Restructuring the app around that hierarchy improved both navigation and meaning. Subjects became the natural entry point into academic content, while assignments and tasks became progressively deeper parts of the same flow. This made the product feel more intentional and better aligned with its actual purpose. In discussion terms, this supports the broader argument that architectural clarity in a small application is not only a technical concern but also a user-experience concern.

\subsection{Why Task-Linked Study Sessions Were Important}

Another important outcome was that the final implementation came to reflect one of the project's original intentions more accurately: the timer was always meant to support concrete study tasks rather than function as a detached utility. This reflects one of the central ideas behind the project, namely that planning and focused work should support each other directly. A generic timer can measure time, but it does not necessarily help the user decide what to work on. By contrast, a task-linked sprint flow makes the act of starting a session more concrete and meaningful in the context of study work.

\vspace{2mm}

This also strengthens the product's unique value relative to broader productivity tools. Study Sprint does not attempt to replace general-purpose planners or offer advanced analytics. Its strength lies instead in the connection between defining study structure and beginning focused work quickly. From that perspective, the later timer-related revisions should not be understood as a change in product direction, but as a process of bringing the implementation into better alignment with the intended identity of the app.

\subsection{Reliability as a Central Product Requirement}

Reliability also became one of the most important concerns during development. This was especially visible in the timer and session lifecycle. Once the app began storing active sessions, supporting break cycles, and recovering state across screens, inconsistencies between local state and stored session data became a real product risk. A timer-based application quickly loses credibility if it cannot be trusted to reflect the user's actual study activity.

\vspace{2mm}

For that reason, the later work on shared session finalisation, active-session recovery, and break-cycle logic was highly significant. These changes may seem less visible than larger UI changes, but they directly support one of the most important, critical product attributes identified earlier in the report: reliability. In practical terms, this means that some of the most valuable work in the project was not the addition of new features, but the correction of weak interactions between existing features.

\subsection{Tradeoffs in Persistence and Scope}

The chosen persistence model also represents a clear tradeoff. Supabase was used for durable user data such as subjects, assignments, tasks, and recorded sessions, while local device storage was used for temporary or device-specific state, such as active-session recovery, study-cycle continuity, and notification identifiers. This was a pragmatic and appropriate design for the scope of the project.

\vspace{2mm}

The benefit of this split is that it keeps the app practical without introducing unnecessary backend complexity. At the same time, it also creates a boundary that must be handled carefully. When one part of the app depends on local control state and another part depends on backend records, consistency problems can arise if the transition between them is not carefully managed. The later reliability fixes suggest that this tradeoff was acceptable, but only when paired with more explicit lifecycle handling.

\subsection{Usability, Onboarding, and Low-Friction Design}

The project also highlights that usability problems in small applications often arise from friction rather than from missing functionality. In this case, several later revisions focused on making the main study flow easier to enter: guided setup was strengthened, default sprint durations were made easier to accept immediately, and help flows were adjusted so that the intended rhythm of focus and breaks became easier to understand.

\vspace{2mm}

These changes support the original product vision well. The main goal of the app was not to maximise customisation or feature depth, but to help users move quickly from intention to action. The discussion that follows from this is that a low-friction default path can be more valuable than a more flexible but slower interaction model, especially in a study-orientated application where hesitation and setup overhead directly work against the product's purpose.

\vspace{2mm}

The claim that the application has a low-friction and intuitive design can also be supported through Nielsen's usability heuristics. Nielsen's heuristics are broad principles for interaction design and are commonly used to evaluate whether an interface is likely to be understandable, predictable, and usable \cite{nielsenheuristics}. Study Sprint was never formally tested through a complete heuristic evaluation with several reviewers, but several of the final design decisions align closely with these principles.

\vspace{2mm}

First, the app supports \textit{visibility of system status} by showing the active timer state, study session progress, completion ratios, and recent activity. This helps users understand what is currently happening and what progress has been made. Second, the app follows \textit{match between system and the real world} by organising academic work through familiar student concepts such as subjects, assignments, and tasks. Third, \textit{user control and freedom} are both supported through options such as cancelling active sessions, editing created entities, and ease of navigation.

\vspace{2mm}

The design also follows \textit{consistency and standards} by reusing cards, pills, action buttons, spacing, and upsert-based forms across similar screens. \textit{Recognition rather than recall} is supported by keeping the parent context visible as users move through the hierarchy, for example, by showing subject and assignment context on deeper task screens. The default sprint flow also supports \textit{flexibility and efficiency of use} because users can start quickly with a sensible default duration while still having the option to choose alternative durations when needed.

\vspace{2mm}

The app follows \textit{aesthetic and minimalist design} by reducing top-level navigation, removing redundant assignment and task tabs, and limiting progress indicators to screens where they provide useful context. Help and documentation are supported through onboarding and lightweight help flows that explain the intended study rhythm without requiring the user to read a large manual. Together, these design choices support the argument that the interface was intentionally shaped to be understandable and low-friction, although a full user test would still be needed to validate this with real users.

\subsection{Limitations of the Project}

Despite the strengths of the final result, the project also has clear limitations. First, the scope remained relatively narrow. This was intentional and appropriate, but it still means that the product does not attempt to cover many surrounding needs that broader productivity platforms address, such as advanced analytics, collaboration, calendar integration, or richer cross-device notification infrastructure. This area would likely be the projects next development path, given a bigger development window.

\vspace{2mm}

Second, the development process remained strongly iterative until late in the project. That was useful for improving the product, but it also meant that some parts of the application changed several times before reaching a more stable form. In report terms, this suggests that the project succeeded more as a process of refinement than as a case of implementing a fully settled design from the start.

\vspace{2mm}

Third, the testing picture appears mixed. The report includes structured tests for important CRUD and guard behaviour, together with repeated use of linting, TypeScript checks, manual testing, and development-build verification. Even so, not all important qualities of the app were verified in the same way. Interaction-heavy behaviour such as timer flow, break handling, onboarding transitions, and notification timing depended heavily on manual validation. This is understandable for the project scope, but it still represents a limitation compared to a larger and more thoroughly automated testing strategy.

\vspace{2mm}

Fourth, the current state of the project is dependent on Supabase and their free-tier rate limits. One obvious concern is the rate of emails being limited to 2 per hour, meaning that within any given hourly timeframe, only two new accounts can be registered due to the requirement of a confirmed email address before a user can log in. This is also an area of expansion for the project; however, the group decided to forego the cost of a subscription, given that the app, in its current state, is used as a proof-of-concept rather than an actual avenue of business.

\subsection{Documentation Lapses}

A further limitation was that the group did not maintain formal time sheets throughout the project. The requirement for time sheets was discovered late, after a vast majority of the product development had been completed. As a result, the group cannot provide a detailed and reliable hour-by-hour record of the work process.

\vspace{2mm}

This weakens the documentation of workload distribution and makes it harder to evaluate the exact amount of time spent. However, the group has still documented the development process through the method section, collaboration description, implementation history, testing section, and final product outcome. The work was also supported by regular communication, meetings, source control activity, and shared report writing. Member contributions can be roughly estimated given the git commit history of each member, although this does not provide a realistic estimate of time spent. Group members also wrote daily work summary notes to document the work that had been carried out and the current state of the development branch at the time of writing. This makes it possible to determine workload distribution based on additions to the codebase. Hourly distribution, however, is difficult to estimate given only work notes and commit history. 

\vspace{2mm}

The group also did not keep any formal ticket list using a Scrum based system. The reasoning was that the app had such limited scope that deploying a full-scale ticket tracking system was deemed to add more complexity to the project than it would alleviate. Given that the planned features for the app were meant to be few but of high quality, the group had no issues staying on top of what each member was working on at any given time, nor did it introduce difficulties in keeping track of future work. With the added benefit of writing work summary notes, the group can also reliably prove the work and contributions of each member. In short; the lack of a full-scale ticket tracking system did not hinder the project in any capacity.
\clearpage

A further limitation was that the group did not maintain formal time sheets throughout the project. The requirement for time sheets was discovered late, after a vast majority of the product development had been completed. As a result, the group cannot provide a detailed and reliable hour-by-hour record of the work process.

\vspace{2mm}

This weakens the documentation of workload distribution and makes it harder to evaluate the exact amount of time spent. However, the group has still documented the development process through the method section, collaboration description, implementation history, testing section, and final product outcome. The work was also supported by regular communication, meetings, source control activity, and shared report writing. Member contributions can be roughly estimated given the git commit history of each member, although this does not provide a realistic estimate of time spent. Group members also wrote daily work summary notes to document the work that had been carried out and the current state of the development branch at the time of writing. This makes it possible to determine workload distribution based on additions to the codebase. Hourly distribution, however, is difficult to estimate given only work notes and commit history.

\subsection{Overall Evaluation}

Taken as a whole, Study Sprint appears successful primarily because the project stayed disciplined about its central problem. The strongest parts of the final application are those where structure, study sessions, breaks, reminders, and progress all reinforce the same user goal. The weaker parts are not signs that the project lacked ambition, but reminders that even a small mobile product becomes complex once reliability, persistence, and user flow are treated seriously.

\vspace{2mm}

The most important discussion outcome is therefore that the project demonstrates the value of coherence over breadth. Study Sprint became stronger when the team removed redundancy, tightened the hierarchy, linked sessions to real tasks, and refined the timer lifecycle until it better supported dependable use. That does not mean the application is complete in every sense, but it does mean that the final result reflects its stated product vision more clearly than the earlier prototype versions did.
